Rule 5.5 and unused extern declarations

[roberto]

Suppose file f.c contains

Code:

extern int a;
extern int f(int x);

but never defines or references that externally-declared identifiers.
Suppose also that the whole program is constituted by f.c and g.c, where g.c contains

Code:

static int a = 3;
static int f(int x) {
  return x+a;
}

Note that there are no other files in the program and that the program is valid C.
In particular, no compilation unit defines or uses the identifiers declared in f.c.

Is this code violating rule 5.5?
Thanks,

Roberto

[MMouse]

Shirely you jest.....

My copy of MISRA-C:2004 says inthe rational for that rule "One example of this confusion is having an identifier name with internal linkage in one file and the same identifier name with external linkage in another file"

Did you read the text with the rule?

[roberto]

Shirely you jest....."

What does that mean?

My copy of MISRA-C:2004 says inthe rational for that rule "One example of this confusion is having an identifier name with internal linkage in one file and the same identifier name with external linkage in another file"

Did you read the text with the rule?

Of course I read it. My doubts concern the notion of "having an identifier name". In concrete, I have file f.c that includes a header file only to get access to a macro. That header file is not included by any other file in the project, and f.c does not use any of the extern declarations in that header file. So the question whether names in the totally-unrelated file g.c should be flagged does not seem completely stupid to me.

[Lundin]

I think the example in the original post violates 5.5, the rule is pretty clear.

Although I also think the rule is strange: it should be sufficient to not give identifiers at file scope the same name as any other identifier at file scope.
Why it is enforced for static variables, I have no idea. It is contradicting, how can the programmer be confused about scope if he wrote static in the
first place? The rule must assume that an incompetent programmer will read code written by a competent one and then get confused because he lacks
knowledge in the C language.

Personally I think we could safely assume that a programmer writing safety-critical applications at least understand the concepts of scope and namespace,
as these are very fundamental and even beginner programmers know of them.

Rule 5.6 is even stranger, to conform with that rule you can't even use "i" for iterators, you must give them unique names... Also, by that rule you
can't name your variables the same as identifiers existing in the compiler libraries, so in order to conform with these two rules, you must read through
all code in the compiler libraries. Without a static analyzer it would be completely impossible to conform with them.

Luckily, both 5.5 and 5.6 are advisory. Is there anyone actually enforcing them in their MISRA implementation?