What can be the alternate way to solve MISRA 2012 Rule 17.3 violation?

Question

MISRA 2012 Rule 17.3 states that a function should never be implicitly declared. However, in this case at line no 6, pf_func is violating the MISRA 2012 17.3 Rule.

typedef unsigned long long uint64;
typedef void (*FOREACH_FUNC)(uint64 ull_key);
void main(FOREACH_FUNC pf_func)
{
    uint64 var;
    pf_func(var);   /*Violation reported on this line*/
}

Here, pf_func is causing violation on MISRA 17.3 Rule. Is this violation valid or is this a bug in the static analysis tool that I am using. Moreover, is there any alternate solution to avoid this violation without changing the workflow of the code?

However, when I modify the code to this-

typedef unsigned long long uint64;
typedef void (*FOREACH_FUNC)(uint64 ull_key);
FOREACH_FUNC pf_func(uint64 ull_key);
void main()
{
    uint64 var;
    pf_func(var);
}

there is no violation reported for rule no 17.3. I am not able to understand the working of function pointer here. Is this the correct or ethical way to solve this issue? Or is there any fault in the static analysis tool itself?

Please include necessary information so it makes faster for people to decipher the problem: **What rule is 17.3?** — user694733, May 04 '18 at 06:39
I consider the question "unclear what you are asking", as long as the rule is not quoted. My favorite search engine did not provide a quote. At least the one I found seems implausible in talking about pointer comparision, which does not match the shown code. Or is the code quote maybe not selected helpfully? — Yunnosch, May 04 '18 at 06:45
MISRA 2012 Rule 17.3 is: "A function shall not be declared implicitly". What tool is saying that 17.3 is being violated? Does it give the same diagnostic if you change the call to `(*pf_func)(var);`? — Michael Burr, May 04 '18 at 06:50
@Yunnosch MISRA-C is not a public document (it costs £10 or so iirc). If you don't have access to the document, you are unlikely able to answer the question regardless if the rule is cited or not. This is not a reason to close the question. However, the question could clarify what broken tool that gave this warning. — Lundin, May 04 '18 at 07:04
@Lundin You are right and that is actually what I wanted to imply indirectly. (Actually I do have access at work, but not here, and more or less "nobody" (as far as OP knows) has.) — Yunnosch, May 04 '18 at 07:08
@MichaelBurr Intriguing. OP, please try this and report the result. In my experience, those static code analysers often can be tricked by little sleight-of-hands like that. — Yunnosch, May 04 '18 at 07:10
And this tool does not complain about the completely broken signature of your `main` function? — Gerhardh, May 04 '18 at 07:25
@Gerhardh This is likely a freestanding implementation, and as such the form of main is always implementation-defined. [See this](https://stackoverflow.com/a/31263079/584518). — Lundin, May 04 '18 at 07:45
@user694733 I have updated the question with the short description of MISRA rule 17.3. — Vishal, May 04 '18 at 08:16
You could give us a clue, and advise us as to which line of code your tool is complaining about - there is no obvious Rule 17.3 violation here. — Andrew, May 07 '18 at 04:51
@Andrew, It is reporting at line no 6 where pf_func is called. — Vishal, May 08 '18 at 06:23
I too am curious whether explicitly dereferencing the pointer helps. My guess is that the checking tool sees what looks like a normal function call and sees that there's no declared function of that name. Personally, I dislike code which makes indirect function calls that "look" like normal function calls, so I'd favor the change even if the tool didn't squawk. — supercat, May 20 '18 at 01:01

score 4 · Accepted Answer · answered May 04 '18 at 07:01

Rule 17.3 is "a function shall not be declared implicitly" and refers to the old C90 way of allowing function calls even when no prototype format declaration is present.

Your code does not do this. All it does is to call a function through a function pointer. So there is no MISRA violation, this is a false positive and a tool bug in your static analyser.

However, assuming you use C99 or later, it is preferred to use stdint.h over home-brewed integer types.

What can be the alternate way to solve MISRA 2012 Rule 17.3 violation?

1 Answers1