Function pointers should be typedef'ed

[jphickey]

CF uses function pointers to implement its state machines, but generally do not use a "typedef" for this, they are mostly declared inline. For example:

CF/fsw/src/cf_cfdp.c

Lines 153 to 154 in a894069

	static void (*const state_fns[])(CF_Transaction_t *) = {CF_CFDP_RecvIdle, CF_CFDP_R1_Recv, CF_CFDP_S1_Recv,
	CF_CFDP_R2_Recv, CF_CFDP_S2_Recv, CF_CFDP_RecvDrop};

CF/fsw/src/cf_cfdp.c

Line 170 in a894069

static void (*const state_fns[])(CF_Transaction_t *) = {NULL, NULL, CF_CFDP_S1_Tx, NULL, CF_CFDP_S2_Tx, NULL};

Not only is this hard to read, it does not facilitate or encourage any sort of uniformity/consistency in the dynamically-called functions. No doubt this is likely a contributor to the fact that some functions take a pointer to the PDU header and some do not (see #90, #91).

Recommendation to fix:

• Determine a common set of arguments that all "state handler" functions are likely to need - from initial inspection, this is probably a pointer to the transaction structure, a pointer to the current PDU header, and a generic/opaque argument for any additional data (this may or may not be needed/used now, but future proofs the calling conventions in case state-specific data becomes needed)
• Declare a global-scope function pointer typedef that conforms to that spec (accepting the standard set of args)
• Convert all "dispatcher" code to use that typedef.

This will not only make the code more readable (function pointer syntax in C is particularly messy) but also encourage more uniformity on the arguments and patterns of state handler functions. It will likely help solve the fact that some functions read their packet data from a global, while others read it from a passed-in pointer (and mixed within the same processing cycle!).