Re: do { quit; } else { }

On 10/04/2025 17:41, Kaz Kylheku wrote:

On 2025-04-10, David Brown <david.brown@hesbynett.no> wrote:

So currently, I have no explanation for why you may write "static int
foo; extern int foo;" and have "foo" be internal linkage, while "extern
int foo; static int foo;" is not allowed.

 What's also not allowed is "static int foo; int foo;" !
 It's because "extern" means "refer to the existing file scope
declaration of the identifer if there is one propagating its
properties, including linkage; otherwise if it doesn't exist,
create an external linkage reference"
 

That's a summary of how "extern" works, but it results in a kind of circular argument or tautology - it's just saying "extern means what it means".  It does not explain /why/ it works this way, or where the rules came from, why C has use of a single keyword that works this way, and why it is called "extern".
It would be much simpler if we had "static int x;" to mean "declare x with internal linkage and define it", "extern int x;" to mean "declare x to have extern linkage", and "int x;" to mean "declare x with external linkage and define it".  That is how you use these in most circumstances (and there are gcc warning flags to enforce it, for those that want to do that).
C rarely makes things more complicated without a good reason.  You gave the example of using "extern" for "unshadowing" an identifier (thank you for that example!), but it doesn't strike me as sufficient justification.  I had thought the reason for the way "extern" and "static" interact was historical compatibility, but that does not appear to be the case.