Re: do { quit; } else { }

David Brown <david.brown@hesbynett.no> wrote:

 
There is no "import" or "export" in C - only "internal linkage" or
"external linkage" - file local or program global, if you prefer.  The
combinations "declare with external linkage but do not define" and
"declare with external linkage and define" are used to achieve import
and export of identifiers.
 

But its home module sees both of these, including the
'extern' version, but here 'abc' is exported!

 
Yes - "extern" does /not/ mean "export".
 

 
That is counter-intuitive: how can a module both import a name (via
'extern int') and export it (via 'int' without 'static')?

 
If the keyword "extern" were written "export", I'd agree on it being
counter-intuitive.  But it is not written that way.  The point of
"extern" is that it indicates external linkage - program-wide sharing of
the identifier in question.  It is shared amongst the units that exports
it (by defining it) and units that import it (by using it), usually
achieved by having the same shared header included by the exporting unit
and the importing units.  This has a huge advantage compared to
languages where importing units read some kind of interface import file
but the exporting one does not - it is extremely easy in C to ensure
that all your shared identifiers match up correctly by keeping all
external declarations in shared headers and all definitions in C files.

The only advantage of C rules is compatibility with linkers used
in seventies.  More precisely, better languages need to implement
some mechanizm to propagate information between source files
and in some cases also do part of linking (gcc has 'collect2'
for such purposes).

C header files work "good enough", but really have no advantages
(except for backwards compatibility and ease of implementation)
compared to proper module system.

--
                              Waldek Hebisch