diamond@csl.sony.co.jp (Norman Diamond) (10/11/89)
The grammar given in the standard does not permit an empty source file. Strangely enough, a preprocessor source file may be empty, but since it cannot generate a non-empty real source file, error detection is only delayed. However, in 2.1.1.2, phase 2, "A source file that is not empty shall end in a new-line character, ...." Why the condition "that is not empty"? Did the committee intend to allow an empty source file, but forgot that somewhere along the way? -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
kdb@chinet.chi.il.us (Karl Botts) (10/15/89)
In article <10955@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes: >The grammar given in the standard does not permit an empty source >file. Strangely enough, a preprocessor source file may be empty, Are you sure this is true; I find it hard to believe. It is quite reasonable and not uncommon to have source files which are empty after the preoprocessor gets done with them. I have had such in the past, and have explicitly tested it on xeveral compilers, and empty source files do compile to do-nothing objects, which seems right to me. Maybe you are thinking of an empty program, which is of course illegal; the address of main() must be resolved somehow.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/16/89)
In article <9802@chinet.chi.il.us> kdb@chinet.chi.il.us (Karl Botts) writes: >Are you sure this is true; I find it hard to believe. It is quite >reasonable and not uncommon to have source files which are empty after the >preoprocessor gets done with them. I have had such in the past, and have >explicitly tested it on xeveral compilers, and empty source files do >compile to do-nothing objects, which seems right to me. Unfortunately, many linkers do not accept contentless object modules. If you say that's a stupid way to design linkers, I would agree, but it doesn't change the fact that such linkers exist. Therefore the "universal" definition for the language must require of a strictly conforming (i.e., maximally portable) program that it contain SOMEthing. Actually, I think this should have been: SOMEthing with EXTERNAL LINKAGE, since about as many linkers have problems with that as with empty objects. The proposed Standard does not seem to specify this the way I thought we intended; it seems to permit a translation unit to have just an object declaration with internal linkage, so long as the object is not used in an expression.
ckl@uwbln.UUCP (Christoph Kuenkel) (10/17/89)
In article <9802@chinet.chi.il.us>, kdb@chinet.chi.il.us (Karl Botts) writes: > [..................................................]. It is quite > reasonable and not uncommon to have source files which are empty after the > preoprocessor gets done with them. I have had such in the past, and have > explicitly tested it on xeveral compilers, and empty source files do > compile to do-nothing objects, which seems right to me. There are loaders which have trouble with modules without symbols! You'd better insert something like #if cond usefull code #else static nop() {} #endif and hope that the optimizer does not strike you :-) -- # include <std/disclaimer.h> Christoph Kuenkel/UniWare GmbH Kantstr. 152, 1000 Berlin 12, West Germany ck@tub.BITNET ckl@uwbln {unido,tmpmbx,tub}!uwbln!ckl
daw@cbnewsh.ATT.COM (David Wolverton) (10/25/89)
This discussion (and, apparently, the ANSI committee members) seem to be confusing the LANGUAGE with its IMPLEMENTATION. Suppose the ANSI (draft) standard allowed empty translation units. It is still very easy to implement a compiler for this near-ANSI C on a machine whose linker requires "some symbol, any old symbol" in each and every translation unit. One must simply ensure that the compiler, if it notices that no symbols have been emitted, emits the equivalent of "static int __my_dummy_symbol;" for each and every translation unit. If, as Doug(?) suggested, a linker might even require that the symbol have external linkage, then it would take a little more work to manufacture a suitable non-conflicting symbol name. But the point is, the implementation can be responsible for this issue, the language definition doesn't need to be a watchdog here. Dave Wolverton daw@attunix.att.com