Not Keil specific; one for the 'C' experts:
Why would one put 'static' variables definitions in a header?
eg, in a header file:
/* * TCO count to temperature conversion table. */ static erTcoTableStruct tcoTableOPUS1[] = { /*{TCO,Temp,} */ {1,-99}, {4,-45}, {5,-40}, {8,-35}, {11,-30}, {16,-25}, {22,-20}, {29,-15}, {37,-10}, {48,-5}, {61,0}, {78,5}, {99,10}, {124,15}, {153,20}, {188,25}, {227,30}, {270,35}, {315,40}, {365,45}, {420,50}, {481,55}, {549,60}, {625,65}, {710,70}, {805,75}, {910,80}, {1010,85}, {1060,88} };
AIUI, the whole point of so-called "header" files in 'C' is to share stuff between source files;
But the whole point of the 'static' keyword (at file scope) in 'C' is to make stuff private so that it is not visible to other modules - ie, not shared.
So I can't see why one would want to have 'static' definitions in a header?!
Original question for this thread: I think the developer was a fool who didn't understand the meaning of static.
If it had been some semi-clever way to create multiple identical initialized variables, then the source code should have contained very explicit comments about this very specific (ab)use to make other developers aware of the very important issue.
I do not like static variables in a header file. If I play with grep, I want to know the meaning when I get a hit on "static" and <my_variable_name>.
If I see "static int my_variable;" in a header file, then I will have to do a scan of a lot of source and header files to figure out where that variable (or in this case potentially multiple instances) may end up.
But I do like to use a global include file for the majority of all other includes and important declarations.
As mentioned earlier, it makes sure that header files are included in the direct order. An alternative would be to write header files like:
#if !defined(XXX_H) #define XXX_H #include <yyy.h> #include <zzz.h> ... typedef struct { ... }; #endif // XXX_H
And as also mentioned earlier, it makes sure that all parts of the code is configured to build for the same target platform - no mixup of include files for LPC17xx and LPC23xx or other instances where the header files may be so similar that code written for one processor may actually compile even with the wrong header file used.
If I have a project that does allocate variables in a header file, then I make sure that the module that gets the variables will also see the corresponding external declaration, to catch incompatibilities. If I do change the variable to 16-bit unsigned, I want the compiler to verify that the external declaration isn't still saying 8-bit signed or something other silly.
The compiler can catch quite a lot of common errors, if source code is written and updated according to some rules.