Rule 16.4

[Lundin]

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.

[sparker]

"16.4 The identifiers used in the declaration and definition of a function 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):

[...]

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

The identifiers in question here are the names of the parameters. It is to prevent you doing this:

Code:

/* x.h */

void x(T a, T b);

/* x.c */

void x(T b, T a)
{
    /* ... */
}

Here I have swapped two identifiers, which could be quite confusing. I could have simply misspelled them. Either way you run the risk of a parameter not being what you think it is.

Is this a big cause of software faults? Not that I've noticed. But it doesn't seem like a terrible rule.

stephen

[Lundin]

Alright, so it seems I have misunderstood rule 8.3. I thought it said that the declaration and definition should be identical. But it only states that their parameter and return types should be identical, without mentioning the identifiers.

That doesn't make the situation better though. This means that in chapter 8 there is a rule stating that the types should be identical, and in chapter 16 there is a rule stating that the identifiers should be identical. It seems to be unecessary fragmentation of the document.

Why not simply make one single rule?

Rule 8.x (required):
\"The function prototype shall be identical to the function definition by the letter, with the exception of the function's linkage.\"

Replaces rule 8.3, rule 16.4 and half of rule 8.4.

[misra-c]

The correct interpretation is that the identifiers in question here are the names of the parameters.

Lundin wrote:

Why not simply make one single rule?

Rule 8.x (required):
\"The function prototype shall be identical to the function definition by the letter, with the exception of the function's linkage.\"

Replaces rule 8.3, rule 16.4 and half of rule 8.4.

Thank you for the comment. It is often difficult to consider the best place for a rule. We will consider the placing of the rules again for MISRA-C version 3.