levy@ttrdc.UUCP (Daniel R. Levy) (06/13/88)
A while ago, on comp.lang.c, I brought up a point about the trouble "volatile" might cause in that it would imply license to a compiler to consider all variables not so labeled to be non-volatile. This in conjunction with an optimizer which misses no tricks would break old code which depends on volatile behavior of, say, globals. I further expressed the desire that if "volatile" were kept, that there also be specified a way (e.g. compiler flags) of telling the compiler not to assume everything not so labeled is non-volatile without having to actually go in and edit the code manually. I also asked in con- junction with this if the proposed ANSI C standard had anything to say about flags to the compiler. Someone responded (I can't find the article now) and said that the proposed ANSI C standard considers each variation in the behavior of a compiler as influenced by, say, an external flag to be a separate implementation. Perhaps this language puts my proposal beyond the self-described scope of the proposed standard (does it really?) but my question now, is: WHY does the proposed standard say this? The definition if taken literally is silly. If it be taken literally, this means each UNIX C compilation system out there comes with billions of "implementations" of the compiler (considering all the different things that can be defined on the command line with -D and the various permutations of optimization, etc. flags). I could perhaps understand this attitude if there are C compilation systems out there that have no way of implementing compile-time directives but that also seems silly to me. (Like, the compiler has to be told where the input and output are, right? Why can't it be told more?) De-mystify me, please? -- |------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY | AT&T Data Systems Group | Weinberg's Principle: An expert is a | Skokie, Illinois | person who avoids the small errors while |-----Path: att!ttbcad!levy-----| sweeping on to the grand fallacy.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/13/88)
In article <2746@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >WHY does the proposed standard say this? What would you prefer that it say? I bet you can't word your notion in a form acceptable for use in a standard. The basic problem is that the Standard would have to discuss non-conforming implementations in order to specify which variations in invocation would be conforming, but by its nature the Standard cannot impose requirements on non-conforming implementations. Another problem is that there is no universal way of invoking compilers.
flaps@dgp.toronto.edu (Alan J Rosenthal) (06/15/88)
Because it accepts a different language, even though it is only a slightly different one.
rns@se-sd.sandiego.NCR.COM (Rick Schubert) (06/15/88)
In article <2746@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: > I also asked in con- >junction with this if the proposed ANSI C standard had anything to say about >flags to the compiler. > >Someone responded (I can't find the article now) and said that the proposed >ANSI C standard considers each variation in the behavior of a compiler as >influenced by, say, an external flag to be a separate implementation. > >Perhaps this language puts my proposal beyond the self-described scope >of the proposed standard (does it really?) but my question now, is: WHY does >the proposed standard say this? My understanding of this is that a compiler flag can have a profound effect on the behavior of the compiler, <<potentially>> having the effect of invoking a separate implementation. For example, the compiler may have something similar to: if (strcmp(*argv,"-x") == 0) compiler1(); else compiler2(); where compiler1() and compiler2() <<are>> separate implementations. This is an extreme example, but various flags can have varying degrees of effect on the compiler. Even though most flags will not affect the compiler on issues related to conformance to the Standard, the potential is there, and it would be difficult for the Standard to specify what types of flags were allowed and what types weren't. I think this is what Doug Gwyn was getting at when he responded: : What would you prefer that it say? : I bet you can't word your notion in a form acceptable for use in a standard. > >De-mystify me, please? Are you de-mystified? -- Rick Schubert (rns@se-sd.sandiego.NCR.COM)
tanner@ki4pv.uucp (Dr. T. Andrews) (06/17/88)
In article <1543@se-sd.sandiego.NCR.COM>, rns@se-sd.sandiego.NCR.COM (Rick Schubert) writes:
) ... For example, the compiler may have > something similar to:
) [ strcmp(*argv,"-x") ? compiler1() : compiler2() ]
) This is an extreme example ...
I wouldn't call it a particularly extreme example. You get a
different compiler (including different parser) under SCO xenix
on the iAEC-386 if you ask for 16-bit code. This is done with a
command line switch ("-M0", "-M1", "-M2").
You can also get a different linker by adding "-dos" to your
command line.
I think, therefore, that it is reasonable to consider different
command line options to give potentially different implementations.
Sometimes they do!
--
rutgers!bpa!cdin-1!cdis-1!ki4pv!tanner (better than it looks!)
or... {allegra codas killer decvax!ucf-cs}!ki4pv!tanner