Rule 8.7 clarification needed

[GerlindeKettl]

I have a project with functions which architecturally belong to one file and have external linkage so that they can be called from other parts of the software. A code checker tool claims that if one of these functions is called only from one other file in the project, this is a rule 8.7 violation and that I should move the definition of the function to the file which calls it (which would mess up the functional partitioning). Is this really intended by rule 8.7?

The rationale of the rule says: “Similarly, reducing the visibility of a function by giving it internal linkage reduces the chance of it being called inadvertently.” So, I've interpreted this rule as "if you use a function only in the translation unit where it is defined, make it static". But for example library functions are intended to be called by anyone who needs them and cannot be called inadvertently.

Could you please clarify what the correct interpretation is?

[dg1980]

First, this rule is categorized as advisory, so technically you don't even need a formal deviation.
Secondly, you talk about library functions.
Does that mean a third party library not under your source control?
Then we are talking "adopted code" in terms of MISRA Compliance 2016 (see https://misra.org.uk/forum/viewtopic.php?f=241&t=1561).
In that case you could create a relaxed guideline re-categorization plan (GRP) and even disapply rule 8.7 for third party libraries (Note: this is only possible because the rule is advisory).

[GerlindeKettl]

Yes, we could disapply the rule for compliance reasons but this is not our goal. We would like to apply this rule (at least in our way to interpret it) and also check it with a code checking tool. When we asked the tool vendor to fix all the false positive messages related to rule 8.7, they denied that and claimed that these were real violations of the rule. This was something we did not expect and so I'm asking for clarification.

[dg1980]

OK, but rule 8.7 for once leaves absolutely no room for any interpretation whatsoever (not always the case with MISRA rules).

Let's assume your whole project consists of foo.c and main.c:

Code:

/* foo.h*/
#ifndef FOO_H
#define FOO_H

extern void foo(void);
extern void bar(void);

#endif
/* foo.c*/
#include "foo.h"

void foo(void)
{
}

void bar(void)
{
  foo();
}
/* main.c*/
#include "foo.h"

int main(void)
{
  bar();
  return 0;
}

The external declaration of foo violates rule 8.7 because it is not called from any other module.
The external declaration of bar on the other hand would be a bug / false positive from your code checking tool if reported as violation of rule 8.7 because it is called from main.c.

[GerlindeKettl]

I agree with you, but my tool vendor does not agree that bar is a false positive. They say as it is called only from one file (main.c), it is a violation of rule 8.7 and that bar should be defined in main.c.

[dg1980]

Ah, now i see where this is going, sorry.
Your tool is very aggressive.
I count the definition of bar in foo.c as "referenced" in a second translation unit apart from main.c and would be just as surprised as you:)
It depends on how "referenced" is interpreted by MISRA and tool vendors then -> official answer needed

[misra-c]

The term "referenced" in the headline includes both the a call of a function and the definition of a function. A function which is defined in one translation unit and called in a different translation unit is compliant with this rule.

An example of this compliant situation occurs in the example suite. Function R_8_7_2 is declared in a header (R_08_07.h), defined in R_08_07_2.c and called in R_08_07_1.c.