search

nasa / PSP

The Core Flight System (cFS) Platform Support Package (PSP)
Apache License 2.0
67 stars 57 forks source link

Simplify Function Pointer Manipulations #46

Open skliper opened 5 years ago

skliper commented 5 years ago

There are a number of places within the CFS Projects where the usage of Function Pointers is somewhat obfuscated by the inclusion of redundant operators. Removing those operators can improve the clarity of the code.

The redundancies are based on code that, when written, did not properly base itself on the following aspects of Function Pointers in the C programming language.

  1. Function names decay into Function Pointers in the same way that Array names decay into pointers to their first elements, which means that an & operator is redundant when setting a pointer to point at a function. For the classical example of this, see most qsort examples, where no & is applied to the comparison function when passing it as the last argument, which has type ''pointer to function...''

  2. The function call operator (''args'') operates on a function pointer -- so every function call you see actually is invoking the above decay semantics. This means that the * operator is ''not'' needed when calling a function via a function pointer. Happily, this also often means that you also do not need an extra level (or two?!) of parentheses to asure that the * is applied to the function pointer and not to the return value.

  3. Calling a function pointed to by a structure member is a very common operation, and with the above in mind, note that there is no parsing or evaluation order ambiguity; no extra parentheses are required to assure that . and -> and the function call operator are evaluated in the proper order.

My task -- embodied in this ticket -- is to seek out cases in the PSP source code where redundant operations are applied to function pointers (at assignment sites ''and'' at call sites), and provide recommended changes to improve clarity.

Specific examples will accumulate in the Comments below.

Ticket to be closed when my scan of the project is complete, and all call sites have been resolved (whether the resolution is to improve them now, file a ticket for later improvement, or where we will be leaving the code unchanged).

''(This also makes the code robust against the rare but troublesome case where an external function changed from a function to a function pointer ... we may never do this, but it is always good to foster good code hygene.)''

skliper commented 5 years ago

Imported from trac issue 42. Created by glimes on 2015-09-09T12:22:04, last modified: 2019-08-14T14:13:14