Re: do { quit; } else { }

On 10/04/2025 20:05, David Brown wrote:

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).

It can't be that simple in C because of shared headers.
If module A wants to export 'abc' to other modules, then the source code seen by the compiler for A.c has to look like this:
      extern int abc;     // in A.h
      ......
      int abc;            // in A.c
The other modules include A.h and see 'extern int abc' which means 'abc' is imported. But its home module sees both of these, including the 'extern' version, but here 'abc' is exported!
That is counter-intuitive: how can a module both import a name (via 'extern int') and export it (via 'int' without 'static')?
You can't say that A.h is only for consumption by other modules, since it could include stuff that all module including A will need, such as macros, types and enums.
So, here C is complicated because the same attribute has to mean different things depending on whether this is the entity's home module or not.

 C rarely makes things more complicated without a good reason.

C usually makes things more complicated without a good reason!
Here's one example, of dozens, of perfectly legal C:
   long unsigned const long const const typedef int A;
   int long unsigned const long const const typedef A;
   long unsigned const long const typedef int A;
   .....