MISRA Discussion Forums
16.9 Reference to function pointer or not - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.16 Functions (https://forum.misra.org.uk/forumdisplay.php?fid=47)
+---- Thread: 16.9 Reference to function pointer or not (/showthread.php?tid=903)

16.9 Reference to function pointer or not - hele - 05-06-2012

Code:
typedef void (*fp)(STATE_MACHINE *sm, EVENT input);
struct STATE_MACHINE_
{
  fp fp_cur_state;
};

void stm_Startup   (STATE_MACHINE *sm,  EVENT input);
Code:
STM_STATE_MACHINE *sm;
sm->fp_cur_state = &stm_Startup;
or
Code:
sm->fp_cur_state = stm_Startup;
??

I have two tools to check code for Misra C.
Checking version without & to the function pointer with Tastking I get the error:
Quote:MISRA-C rule 16.9 violation: [R] function calls with no parameters should have empty parentheses
What in fact means the exact rule (I guess):
Quote:MISRA-C rule 16.9 violation: [R] A function identifier shall only be used with either a preceding &, or with a parenthesised parameter list, which may be empty.

checking with PC-Lint with & I get
Quote:sm->fp_cur_state = &stm_Startup;
stateMachine.c 72 Warning 546: Suspicious use of &

What's right? I guess functionality should be the same in both cases.

Re: 16.9 Reference to function pointer or not - misra-c - 18-06-2012

The version without the & operator is certainly a violation of Rule 16.9. The rule requires that any use of an identifier that designates a function (stm_Startup in the example) have a & operator unless the identifier is being used to designate a function in a function call. So, the Tasking tool is correct to diagnose a violation of Rule 16.9.

The version with the & operator is legal C. As described in the C90 standard, Section 6.2.2.1, a function designator is converted to a pointer to function except when it appears as the operand of a sizeof operator or a & operator. Some tools therefore diagnose an & operator applied to an identifier that designates a function because the & operator is redundant in this case. This probably explains why PC-lint issues a diagnostic.

You would need to ask your support contact for PC-lint why it is not diagnosing a violation of Rule 16.9 for the version without the & operator. It might be that the tool needs to be configured differently.