simons@think.com (Joshua Simons) (08/01/90)
I am having trouble deciding how to deal with the following one-line
compilation unit:
int a[] ;
3.7.2 seems to say that this is a tentative definition and that it
should be treated as if it has an 'initializer equal to 0'. I'm not
sure if this applies in this case, and if it does apply, what it
means. Is the Standard saying that the above is equivalent to:
int a[1] = { 0 } ; ?
Intuitively, I would think that my original should be equivalent to:
extern int a[] ;
That is, it isn't a tentative definition...it is just a declaration
which references something in another compilation unit. But I can't
figure out how to read the Standard to get that interpretation.
Help please?
-josh simons
--
simons@think.com
thinking machines corporation
245 first street tel: 617.876.1111
cambridge, ma 02142-12114 fax: 617.876.1823gwyn@smoke.BRL.MIL (Doug Gwyn) (08/02/90)
In article <41187@think.Think.COM> simons@think.com (Joshua Simons) writes: >int a[] ; >3.7.2 seems to say that this is a tentative definition and that it >should be treated as if it has an 'initializer equal to 0'. More importantly, it's an incomplete type that must be completed by the end of the translation unit. If no initializer is given for the declaration that completes the type, nor for any other external declaration of the same (file-scope) object, assuming they all lacked the "extern" storage-class specifier, then all the declarations were tentative definitions, and in effect at the end of the translation unit an external (composite-type) definition for the object is created by the compiler and 0s are supplied as initial values. >Intuitively, I would think that my original should be equivalent to: >extern int a[] ; >That is, it isn't a tentative definition...it is just a declaration >which references something in another compilation unit. But I can't >figure out how to read the Standard to get that interpretation. Nope. A file-scope declaration doesn't become an external reference merely because it has incomplete type. I think you're thinking of the "common" model for external objects, as implemented in earlier UNIX C compilers; however, the Standard requires a def/ref model, as specified in K&R 1st Edition. This is a case where X3J11 backed implementors who had followed the de facto language standard (K&R Appendix A) rather than the UNIX implementation. (Forbidding macro argument substitution within string literals etc. was another such case.)