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

I don't think so.

"no real information is defined for header files."

Header files are just verbatim text inclusion, so the Compiler itself knows nothing about them.
They are effectively irrelevant as far as the Compiler is concerned.

"If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined."

But that's not happening here - the header file is just creating identifiers with internal linkage. Nothing else.

I don't think so.

"no real information is defined for header files."

Header files are just verbatim text inclusion, so the Compiler itself knows nothing about them.
They are effectively irrelevant as far as the Compiler is concerned.

"If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined."

But that's not happening here - the header file is just creating identifiers with internal linkage. Nothing else.

But since each source file is it's own 'translation unit' there are no requirements to flag this usage. is in effect what you stated: "the header file is just creating identifiers with internal linkage"

And since the header files are "just verbatim text inclusion" if its syntatically correct, including using static keyword, can be used. The 'loophole' being just that, that there either should be some limitation or flagging of this type of use within a non-source or non .c file.

Just my opinion.

I know it is syntactically correct - that wasn't the question.

The questions was why anyone would want to do it?

So you can further argue your point of view??

I think this question has been answered. The developer explained the reasons for why it was used, which is more than you can usually expect from a code snippet.

It was also estabished that this is not the most efficent way to code. But, the developer seems to be in high regard within this community and I personally have no issue with the way he wants to code something. If it is a preference, and it does not violate the responsibilities entrusted to an engineer regarding safety and reliability then it is allowed.

Would I use this approach? I believe that question has also been answered.

There is no absolutely correct way to code to solve a problem. There are only more efficient and effective ways to do it. If the coding solution is accomplished within established guidelines and is well documented so be it. The fix would be easy enough: static --> const

Finally, if it is expected that someone else will post the why to this question, knowing full well the bias of this thread regarding why you should not use this approach, given a choice, do you really expect someone to do this? Only if they like to argue a point.

As far as I'm concerned, this was nothing more than an academic exersize.

Cheers.

Are you referring to Cpt Vince?

He was not the developer of the code that I cited in my original post!

I think you've got sidetracked onto a discussion of the way he manages his header files.
That wasn't my original question!

My question was, what could be the point in having static definitions in a header file (irrespective of how you manage your header files); in other words, what could be the point in having multiple identically-named and identically-typed but distinct objects in the files of a project?

"As far as I'm concerned, this was nothing more than an academic exersize."

Well, I've got code like that, and I can't see any good reason for it - so I was wondering if anyone could suggest one.

Unfortunately, the discussion got sidetracked into different ways of managing headers - which wasn't the point.

My question was, what could be the point in having static definitions in a header file (irrespective of how you manage your header files); in other words, what could be the point in having multiple identically-named and identically-typed but distinct objects in the files of a project?

I congratulate you for your persistence!

The only halfway sensible reason I can come up with (which I think someone else already suggested) is to allow the instance of the struct local to each source file to modify its local instance at runtime. I'm sure someone, somewhere will have managed to find a reason to do this.

Regarding some of the other stuff in this thread:

For the confused:
From the compiler's perspective include files don't exist, so special handling is not an option.

For the deluded:
The convention in 'C' programming is that header files do not include any code that allocates storage. Everyone goes through the "oh but I've got this great way of using header files that's much better/safer/controlled than the usual way" during their learning curve. Fortunately most of them eventually realise that the conventional approach is the best one.

When you join a company or a project you adopt the existing conventions, even though those almost certainly aren't the best. Why would you join a community of (presumably) hundreds of thousands of 'C' programmers than decide not to follow convention?

I look forward to the responses...

Thanks!

"The only halfway sensible reason I can come up with (which I think someone else already suggested) is to allow the instance of the struct local to each source file to modify its local instance at runtime."

Yes - Mike Kleshov suggested it.

Anyone (else) got any other ideas?

The questions was why anyone would want to do it?

Far more likely than not because they have no idea what they're doing.

Just because there are people doing something doesn't mean that valid reasons exist for doing it.

Yes, that is very much the impression I get from the code in question!

:-(

"Just because there are people doing something doesn't mean that valid reasons exist for doing it."

Indeed!
But I wanted a "second opinion" - in case there was a valid reason that I just hadn't thought of!