External linkage of objects

[Lundin]

I'm sitting here and writing a code standard for our company which includes MISRA-C. Among the first things I did was to ban external linkage of objects (ie variables) entirely, as it is one of the most common causes of \"spaghetti-code\". After doing this, I found myself having an easy time to make my rules conform to the whole chapter \"Declarations and Definitions\". Plenty of the issues addressed won't be any issues at all, if external linkage of objects is forbidden. (External linkage of functions will naturally be allowed, since the prototypes should be in the h-file and the definitions in the c-file.)

If external linkage of objects was forbidden, it would smoothen plenty of the rules, as they would then only apply to functions and not objects. 8.4 and 8.12 could probably be removed entirely.

So I am curious why MISRA didn't forbid it?

No matter how hard I try, I can't come up with a situation where external linkage of objects is motivated. Since the proper way to pass variables between files in C is like this:

Code: Select all

/* module.h */

extern uint8 get_x (void);

extern void set_x (uint8 x_val);

Code: Select all

/* module.c */
#include \"module.h\"

static uint8 x;

uint8 get_x (void)
{
  return x;
}

void set_x (uint8 x_val)
{
  x = x_val;
}

Code: Select all

/* main.c */
#include \"module.h\"

uint8 something = get_x();

set_x (something_else);

This enables the only part of object orientation that ISO C supports, namely private variable encapsulation.

The only argument I can think of against the above method is efficiency. But that is not a good argument, as most compilers support inlining of functions, which will make the above code as efficient as it gets, with direct memory access to the variable. And since that can be done, even hardware registers can be declared this way.

Perhaps there is some case I didn't think of? I would be most curious to know whether MISRA has had this in mind, or perhaps if external linkage was allowed \"to avoid programmer shrieks\", as it is a commonly used syntax?

[George Brown]

Hi Lundin,

If you are able to enforce the banning of external objects, then do so!

But in general, most programs written in C do use external objects.

AUTOSAR allows the direct reading and writing of external objects across the RTE (Run-Time Enviroment). The abstraction of using read_x and write_x handles between software components was considered too excessive. Shame - Given the abstraction, it could have been implemented to degenerate into direct access with no overhead.

What do other people think? Would you like to see a MISRA rule banning external objects?

George

[william.forbes]

Yes.
But I think lots of people will complain!
There is a lot of legacy code that people have to use and hence this may be extreemly difficult to achieve in practice.

Bill Forbes

[misra-c]

It is interesting to note that avoiding external objects achieves compliance with the "Declarations and Definitions" rules. However, there are other methods of achieving compliance and these have the advantage, as noted by william.forbes, of being compatible with legacy code. For this reason, a MISRA rule banning external objects is not currently planned.