storage class ambiguity

Morris Keesan keesan at bbncca.ARPA
Thu Nov 3 07:03:03 AEST 1983


This note is to disagree strongly with John Nelson (genrad!john).
I quote alternately from his message and the "C Reference Manual", 
Appendix A of "The C Programming Language", which I take to be the
final arbiter of what is and isn't "strictly C".

>		 file 1: extern int foo;
>		 file 2: extern int foo;
>This should not generate a loader error, The loader is SUPPOSED to
>allocate storage for foo.
The loader is NOT supposed to allocate storage, as  per
Kernighan and Ritchie, p. 206:
 The appearance of the extern keyword in an external definition indicates
 that storage for the identifiers being declared will be allocated in another
 file.  Thus in a multi-file program, an external data definition without the
 extern specifier must appear in exactly one of the files.

>		 file 1: extern int foo = 8;
>If the compiler generates an error on this, then it is just plain WRONG!
>I cannot emphasize this enough.  The problem is not that the reference
>manual should not say that extern is the default storage class, it IS,
>and any compiler that does not work this way is not strictly C!
When the compiler generates an error on the above, it is behaving RIGHT,
as evidenced by the sentence in Kernighan & Ritchie immediately following
the previous citation.
Kernighan and Ritchie, also p. 206:
 The identifier can be initialized only in the declaration where storage is

>I had a similar problem with the Whitesmith compiler - all externs had to
>be initialized (which could be lived with) but also, static's had to be
>initialized!  If you have:
>		 file 1: static int foo;
>you get the compiler message: "undeclared static foo".  We don't use
>Whitesmiths anymore for this and numerous other non-standard items.

Here I share John Nelson's complaint.  The C compiler for Charles River
Data Systems' UNOS system also requires explicit initialization of statics,
in direct violation of Kernighan & Ritchie, p. 198: "Static and external
variables which are not initialized are guaranteed to start off as 0;"

More information about the Comp.lang.c mailing list