C question: Why would one put 'static' variables in a header?

Dear Captain,

I think that doing what you propose really harms the chance of a less-informed "code-monkey" to correctly maintain C code. I mean, I have encountered too many software spaghettization instances so far, due to:
* Incompetence
* Sloth
* A bad character
* Job security
* Arrogance

I don't want to add "control freak" to this list :-) :-) :-)

Tamir,

Although it might look 'complicated' it really isn't. All too many times people will re-include files that don't need to be included, and will sometimes include the wrong file (esp the SFR files).

Using my method, the code is very structured and all include files are in total control via the "Includes.H" file.

This also adds to the reliability of the code, not to mention repeatability during the debug phase.

Any code-monkey who cannot handle this structure should be taken out back and, well you get the idea.

I think once you have tried it, you'll stick with it.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I agree: having identically-named and identically-typed but distinct objects sounds very dodgy to me!

I think MISRA frowns upon it - even for automatic variables?

Yes, there is merit in having a single header that provides (by conditional compilation) both the definitions and the extern declarations of shared symbols - the practice is quite common.

Just to note that the code in question (in my original post) is not doing any of this definition-here-declaration-there trickery;
It's just a straightforward 'static' definition that is included verbatim in any & every file that #includes that header.

Andy,

I think that 'static' does not mean 'private' unless you are declaring a function. Static, from what I remember, means that the data allocation remains in memory and is not optimized out. Thus an 'extern' to a static should be allowed.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I don't always agree with MISRA.

But since you & Tamir bring up the 'same name' issue, you must realize that the compiler shall complain if it doesn't appear in the 'extern' area in addition to the data-allocation area. So such maintenance shall be caught by the compiler.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Actually, they will be caught by the Linker!

And nothing can catch the error where you thought your were accessing the 'x' in this.c but you're actually accessing the 'x' in that.c...

Can you imagine to total nightmare one code-monkey might end up in, when such statics are passed as parameters, and the wrong/inappropriate configuration is used, but it does not affect the function that is called so the code-monkey can't immediately tell what's happening...?
In other words: Sorry captain, I usually agree with just about anything you write, but not this time...

The key dis-advantage that I see to headers of the form

#if MAKE_DEFINITION
unsigned int x;       // This is a definition
#else
extern signed int x;  // This should be the corresponding declaration
#endif

is that the compiler only ever sees either one or the other; so it can never verify that the two match - or, conversely, report that they don't!

That's why I prefer:
file1.h

extern signed int x;  //  declaration

file1.c

#include "file1.h"    // The declaration is visible

unsigned int x;       // definition:
                      // The compiler can now see both declaration & definition
                      // and, therefore, can report any discrepancy

file2.c

#include "file1.h"    // The declaration is visible;
                      // this file just references the external object

Not quite.

static applied to an automatic variable, as you say, makes its storage permanent.

But static applied to a file-scope variable does make it "private" - or, in spec-talk, gives it "internal linkage".

Yes, I guess that could possibly be useful.

I still think it'd be confusing to have identically-named and identically-typed but distinct objects!

If I actually wanted to do that, I think I'd go for having an "initialiser" function which would apply the common initialisation to objects with meaningfully-distinct names!

"The other possibility is that the author of the code didn't want to make the table 'global', so only the files that include the header can access it"

But then they are not sharing the table - they each have their own distinct copy of it!

Indeed - so what's the point of having it in a header?!

Andy,
I understand your concern. I used copy-n-paste for the externs required.

Tamir,

You are right in that people with lesser skills shall screw things up really fast.

All I can suggest is that you try 'my' method for a small project, and you'll get the hang of it.

The reason I do it this way, is that I realized that the #include process is generally uncontrolled, and I wanted a way of controlling which files get included and when... and to ensure that all common files are indeed common to all modules.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Indeed - so, again, why would one put static definitions in a header file?!

You're declaring them static to localise their scope - so why try to extend it by putting them in a header?!