MISRA Discussion Forums - 6.16 Functions

Is 16.4 violated if 16.3 is?

Thu, 11 Oct 2012 20:23:29 +0000

Given the following code:

Code:
void f(int);

void f(int x){}

Does this code violate rule #16.4, identifiers used in the declaration and definition of a function shall be identical? While the lack of a parameter name in the prototype violates #16.3, I am not sure if violating #16.4 is possible in that case.

16.9 Reference to function pointer or not

Tue, 05 Jun 2012 07:55:04 +0000

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;

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.

Rule 16.8 and 14.7

Fri, 06 Jan 2012 22:35:03 +0000

In rule 16.8 is stated
All exit paths from a function...
whereas rule 14.7 states
A function shall have a single point of exit...

Is there a difference between "exit path" and "point of exit"? If not, should rule 16.8 be interpreted as beginning with "The single point of exit from a function..."?

Regards,

Rule 16.7

Mon, 12 Sep 2011 16:54:11 +0000

Hello,

please look at the following code snippet:

Code:
struct testStruct {

  float32_t varFlt3[3][16];

};

static void f1(struct testStruct * const testStructData);

static void f2(float32_t in_Data[3][16]);

static void f1(struct testStruct * const testStructData)

{

  f2(testStructData->varFlt3);

}

static void f2(float32_t in_Data[3][16])

{

    uint32_t i = 0u;

    for(i = 0u; i < 16u; i++)

    {

      in_Data[0][i] = (float32_t)i;

    }

}

int32_t main(void)

{

  /* This struct should be modified */

  static struct testStruct test;

    f1(&test);

    return 0;

}

My compiler returns a MISRA C rule 16.7 checker error because f1() shall point to a const object. In my opinion, it can't be const, because, the object is modified by f2() inside f1(). The compiler can know this. So who is correct? The compiler vendor or me? If the compiler is correct, how can I overcome this problem? If I modify the parameter of f1() to const I'll get an error because f2() modifies the object, the pointer parameter points to.

Kind regards,

Michael

Rule 16.9

Fri, 26 Aug 2011 20:40:01 +0000

Please consider the following snippet:

Code:
static int foo1(void) {

  return 0;

}

static int foo2(void) {

  return 1;

}

int foo() {

  /* Is the following occurrence of `foo1' compliant wrt 16.9? */

  if (&(foo1) == &foo2)

    return 0;

  return 1;

}

Rule 16.5

Tue, 02 Aug 2011 12:11:26 +0000

Does this rule apply also to function pointers?
If I want to declare a function pointer which can be used for pointers to functions with different arguments, something like the following is useful:

uint8_t (* gen_u8p)();

Is this intended to be prohibited by the rule?

16.3

Fri, 15 Apr 2011 12:52:55 +0000

Just to make sure, does rule 16.3 also apply to declarations of function pointers?

void (*pt2Function)(int);

Sould I give a name to the parameter?
Does that make sense at all?

Rule 16.9 - Error in code example

Sat, 24 Oct 2009 16:18:56 +0000

The code in the normative text of rule 16.9 is:

Code:
if (f)     /* not compliant - gives a constant non-zero value which is

{             the address of f - use either f() or &f */

    /* ... */

}

Maybe it should be:

Code:
if (f)     /* not compliant - gives a constant non-zero value which is

              the address of f - use either f() or &f */

{

    /* ... */

}

Note - the opening brace was inside the comment.
A trivial error but maybe it should get corrected?

Rule 16.4

Mon, 04 Feb 2008 14:22:36 +0000

I wonder if rule 16.4 fills a purpose, as it seems to be well-covered by several other MISRA rules.

\"16.4 The identifiers used in the declaration and definition of a function shall be identical.\"

\"8.3 For each function parameter the type given in the declaration and definition shall be identical, and the return types shall also be identical.\"

8.3 has both the parameters and the return type covered, all is fine there. Therefore I assume that rule 16.4 only applies to the function name itself. Ie it would be interpreted as \"the function identifier used in declaration and definition shall be identical\".

So as far as I understand it, rule 16.4 would only apply when the names in the function definition and the declaration are different, ie the scenario where the function definition is \"apples\" but the function declaration is \"bananas\" (although their parameters and return types are identical, as covered by rule 8.3):

Code:
static void apples  (uint8_t n);

static void bananas (uint8_t n)

{

}

int main()

{

  apples(x);  /* A linker error will occur, apples() isn't found and the program won't be executed. */

  bananas(x); /* This will work fine but the prototype \"apples\" is redundant. */

}

The above behavior is the same if the function definition is placed in a h-file and the function is called from another file.

The \"bananas\" case will never result in faulty program behavior, assuming rule 8.3 is fulfilled. Also, this case would violate rule 8.1 \"Functions shall have a prototype...\". And if the bananas function had been placed below main() instead of above, the code wouldn't even compile.

So I fail to see the point of rule 16.4, it seems redundant to me.

Rule 104 question on function pointers

Thu, 03 Mar 2005 21:40:06 +0000

Our product makes use of a \"service-based\" architecture - and, while it is \"good code\" that runs on 16, 32, and 64 bit environments, it wasn't initially written with MISRA compliance in mind, although we're \"pretty close\". The tricky one is Rule 104...

Anyway, since networking, IPC, and other typical PC-and-up options for doing services aren't often available in constrained embedded environments, we've chosen function pointers and a \"registration\" methodology as our approach. We're an ISV that works with customers who typically write services themselves or use one of several service implementations that we provide. Services are things like file-system API interfaces, flash I/O interfaces, memory management, etc.

So, I have a question about Rule 104: it would seem that Rule 104 disallows this sort of approach, if I read it right: services are ultimately dynamically-created structures that contain arrays of function pointers that execute the different operations of the service.

The only \"get out of jail free\" card that I can see is that these pointers are set only once at registration time and not changed while the instance of the service exists. But the function pointers are initialized at runtime, so it would seem that we're still in violation of Rule 104.

Is \"initialized at runtime\" versus \"initialized at compile-time\" the test for Rule 104 compliance? Or is it \"a function pointer that is changed\", versus one that is initialized once, whether at compile or runtime, and not changed afterward?