 |
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: /* module.h */
extern uint8 get_x (void);
extern void set_x (uint8 x_val);
Code: /* module.c */
#include \"module.h\"
static uint8 x;
uint8 get_x (void)
{
return x;
}
void set_x (uint8 x_val)
{
x = x_val;
}
Code: /* 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?
|
