gnu@hoptoad.uucp (John Gilmore) (12/21/88)
I'm glad to finally see some sense about __STDC__ (Ray Butterworth's).
Doug, you seem to be trying to tell us that ANSI C implementations
should all be worthless because they are so pedantic that they can't be
used. The code that I have so far written using __STDC__ uses it to
determine whether the historic-C preprocessor was there or whether the
committee-designed preprocessor was there. This is necessary because
the committee designed a new syntax incompatible with every existing
piece of source code, and disabled the features that old code used.
Now Doug suggests that the only thing that can be relied upon to
distinguish the two environments, be turned off if a minor extension
(like the ability to call open() with either two or three arguments,
without declaring it variadic, or a fortran keyword) is also accepted
by the compiler.
There is probably a use for __STDC__ other than determining whether
you are on an "old" or "ansi" style compiler, but I doubt such uses are
important enough to break the main job of __STDC__.
But most importantly, you can rave all you want about what
non-conforming compilers do with __STDC__, but it's all that much hot
air. "We don't conform, nyaah." is a perfectly reasonable response.
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
"The network *is* the confuser."casey@gauss.llnl.gov (Casey Leedom) (12/22/88)
[[I'm sending this just because I'm pissed at Apollo and the subject conforms to the bitch. If this has already been mentioned on this subject thread, I'm sorry. I just started looking at this group again after a long absence.]] The Apollo SR10 compiler defines __STDC__. It supports functional prototyping. It does not support any other feature of ANSI C that I know of. In particular, I know that it does not support the new "##" preprocessor syntax to generate a null length break between preprocessor macros. This causes breakage in programs which have had a lot of attention leveled at them to make them as portable as possible. Apollo has taken an already difficult conversion task (converting from K&R C to ANSI C) and simply muddied the waters. We will probably see #ifdef __STDC__ #ifdef apollo ... #else ... #endif #endif for many years to come because of this. Three cheers for idiocy at Apollo. [[It should be noted that Apollo doesn't see any problem with the described situation. They don't feel that they are misusing the __STDC__ symbol.]] Casey
diamond@csl.sony.JUNET (Norman Diamond) (12/23/88)
In article <6093@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > The code that I have so far written using __STDC__ uses it to > determine whether the historic-C preprocessor was there or whether the > committee-designed preprocessor was there. This is necessary because > the committee designed a new syntax incompatible with every existing > piece of source code, and disabled the features that old code used. Good thing the committee only considers standardizing practices that have some trial experience, and doesn't invent new features or forms. :-I (I for irony?) -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
diamond@csl.sony.JUNET (Norman Diamond) (12/23/88)
In article <14856@lll-winken.llnl.gov>, casey@gauss.llnl.gov (Casey Leedom) writes: > The Apollo SR10 compiler defines __STDC__. It supports functional > prototyping. It does not support any other feature of ANSI C that I > know of. In particular, I know that it does not support the new "##" > preprocessor syntax to generate a null length break between > preprocessor macros. > [[It should be noted that Apollo doesn't see any problem with the > described situation. They don't feel that they are misusing the > __STDC__ symbol.]] Well. 1. Rhetorical question: If you buy a history book that contains deliberate, fraudulent lies, are you legally entitled to a refund? 2. Sounds like a lot of programmers, who have already put #if __STDC__ in their code, might not mind globally editing __STDC__ to __ANSIC__ after they read this. Perhaps the committee could be persuaded to make that change, and trademark it, before things get any worse. The amount of future effort that could be saved is substantial. (Incidentally, __ANSIC__ might be better than __ANSI__ because there might eventually be __ANSIUNIX__, __ANSIWINDOWS__, etc.) -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/27/88)
In article <6093@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
-Doug, you seem to be trying to tell us that ANSI C implementations
-should all be worthless because they are so pedantic that they can't be
-used.
To the contrary, I think implementations that conform to the Standard
will be extremely useful.
-The code that I have so far written using __STDC__ uses it to
-determine whether the historic-C preprocessor was there or whether the
-committee-designed preprocessor was there.
That of course is one possible use for __STDC__, but by no means the
only one and probably not the most important one.
-This is necessary because
-the committee designed a new syntax incompatible with every existing
-piece of source code, and disabled the features that old code used.
That is of course blatantly false. I know of an experiment involving
the recompilation of every piece of UNIX system source code using an
experimental (intended to be ANSI-conforming) compiler, and very
little of it was "broken" by the standard-conforming implementation.
Now, code that fully uses the features of ANSI C will not be backward-
portable to non standard-conforming compilers, but that was never a
constraint (and was deemed impossible anyway).
-Now Doug suggests that the only thing that can be relied upon to
-distinguish the two environments, be turned off if a minor extension
-(like the ability to call open() with either two or three arguments,
-without declaring it variadic, or a fortran keyword) is also accepted
-by the compiler.
What's a "minor" violation for you may well be "major" for others.
-There is probably a use for __STDC__ other than determining whether
-you are on an "old" or "ansi" style compiler, but I doubt such uses are
-important enough to break the main job of __STDC__.
Funny, that's MY argument!
-But most importantly, you can rave all you want about what
-non-conforming compilers do with __STDC__, but it's all that much hot
-air. "We don't conform, nyaah." is a perfectly reasonable response.
But subverting features of the Standard specifically designed to be used
by application source code to test for implementation standard conformance
is NOT reasonable; it's some sort of crime.casey@gauss.llnl.gov (Casey Leedom) (12/30/88)
| From: Ellis Oliver Jones <oj@apollo.com> | | > From: Casey Leedom <casey@lll-crg.llnl.gov> | > | > [[It should be noted that Apollo doesn't see any problem with the | > described situation. They don't feel that they are misusing the | > __STDC__ symbol.]] | | Mr. Leedom, this is a false statement. Furthermore, you know it | is a false statement. You acknowledged mail from me informing you | that I logged it as a compiler bug. We are struggling to fix this | problem as quickly as possible. | | I wonder who's really muddying the water. Actually you're right I think. I got so much mail from people within Apollo who didn't feel that it was a problem, I forgot yours. I'll post a retraction right away. Please accept my apologies for this misrepresentation. By the way, the quick fix is to leave __STDC__ undefined and provide a compiler switch to allow users to use function prototyping (or accept both syntaxes transparently, but I think that's a difficult problem). The problem is not that your new compiler only provides function prototyping. The problem is that it claims to be an ANSI C compiler. Alternatively, you could drop the SYSV COFF object file format and use GNU cc (or hope that someone gets GNU cc to handle COFF). Then you'd get an ANSI C compiler and a better compiler to boot. Casey
geoff@warwick.UUCP (Geoff Rimmer) (01/13/89)
I think I read in the Microsoft 5.1 C compiler manual that __STDC__ is
defined to be 0 in that compiler, since it doesn't fully comply to the ANSI
standard. If this is so, it makes lines like the following, useless.
#ifdef __STDC__
printf("yabbadabbadoo!!! ansi compat C !!!\n");
#else
printf("uggh! old C\n");
#endif
Anyone know of any other compilers that don't comply with the correct use of
the __STDC__ macro? (I know someone already mentioned apollo which defines
__STDC__ even though it doesn't support the stringizing operator (##))
If I misread the manual, I apologise to Microsoft!
Geoff
------------------------------------------------------------
Geoff Rimmer, Computer Science, Warwick University, England.
geoff@uk.ac.warwick.emerald
"So, this is what a restaurant looks like!"
- Filthy Rich and Catflap, 1986.
------------------------------------------------------------seg@smsdpg.uu.net (Scott Garfinkle) (01/14/89)
From article <898@ubu.warwick.UUCP>, by geoff@uk.ac.warwick.emerald (Geoff Rimmer): > I think I read in the Microsoft 5.1 C compiler manual that __STDC__ is > defined to be 0 in that compiler, since it doesn't fully comply to the ANSI > standard. If this is so, it makes lines like the following, useless. > > #ifdef __STDC__ > ... > #else > ... > #endif No, it doesn't make this "useless." In fact, your example (shortened here) works just fine. You just can't say "#if __STDC_", you have to use #ifdef (or "#if defined()"). > Anyone know of any other compilers that don't comply with the correct use of > the __STDC__ macro? ... According to the AT&T SysV R4.0 (SVR4) Developers' Conference presentation, the SVR4 compiler will, however, be "useless" in the sense above; the MSC compiler defines __STDC__ to 0 because there are some differences and not-fully- implented things (c.f. my recent complaint about (int * const) objects) in MSC5. In SVR4 cc, it *always* defines __STDC__, but sets it to 0 if you tell it you want "old-style C." Kind of strange, I thought. (Maybe I misunderstood them.) Scott E. Garfinkle SMS Data Products Group, Inc. uunet!smsdpg!seg <standard disclaimer>
w-colinp@microsoft.UUCP (Colin Plumb) (01/14/89)
Disclaimer: I have absolutely *nothing* to do with the people writing the Microsoft C compiler. This is a more general statement. Personally, I generally thing setting __STDC__ to 0 if a compiler almost makes it, but will parse ANSI C programs and, for the most part, compile them, is a Good Thing. It's not in violation of the standard, because the standard requires that __STDC__ set to 1. #if __STDC__ == 1 is the way to *really* test for the strictest ANSI compliance. But in 90% of the cases, it *does* handle all that code people are writing that basically has #ifdef __STDC__ /* prototype function declarations and macros using # and ## */ #else /* old style declarations and macros using in-string replacement and /**/ */ #endif as the author "intended". -- -Colin (uunet!microsof!w-colinp)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/14/89)
In article <898@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes: >I think I read in the Microsoft 5.1 C compiler manual that __STDC__ is >defined to be 0 in that compiler, since it doesn't fully comply to the ANSI >standard. If this is so, it makes lines like the following, useless. Sigh. I was afraid that somebody would have a cosmic ray fire in their brain and decide to "#define __STDC__ 0" to be "helpful", and lo! it did. Of course the REAL way to be helpful would have been to not define __STDC__ at all in a nonconforming implementation! One wonders what they were thinking of. Apart from screaming at MicroSoft about this brain damage, I guess we all have now been forced to use "#if __STDC__" to survive that stupid decision.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/14/89)
In article <179@smsdpg.uu.net> seg@smsdpg.uu.net (Scott Garfinkle) writes: >You just can't say "#if __STDC_", you have to use #ifdef >(or "#if defined()"). You got that exactly backward. >In SVR4 cc, it *always* defines __STDC__, but sets it to 0 if you tell it you >want "old-style C." That's the same problem as was reported for MicroSoft. SVR4 hasn't been released yet; perhaps they will fix this before release.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/14/89)
In article <264@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >Personally, I generally thing setting __STDC__ to 0 if a compiler almost >makes it, but will parse ANSI C programs and, for the most part, compile >them, is a Good Thing. We already had this discussion, not long ago in fact. I maintain that predefining __STDC__ is a mistake, except when the implementation conforms to the Standard (in which case __STDC__ is necessarily preset to 1, for the current standard, or some number greater than 1, presumably, for a future compatible standard). There is no way you can know what use a programmer is making of __STDC__. In fact your guess was wrong for some of the code we have..
friedl@vsi.COM (Stephen J. Friedl) (01/15/89)
In article <179@smsdpg.uu.net>, seg@smsdpg.uu.net (Scott Garfinkle) writes: > In SVR4 cc, it *always* defines __STDC__, but sets it to 0 if you tell > it you want "old-style C." Kind of strange, I thought. (Maybe I > misunderstood them.) Even in old-style mode, I believe that SVR4 cc will still take prototypes and other ANSI features. It just follows the old rules as well (value-preserving, etc.) Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for me only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl ---------Nancy Reagan on Hawaiian musicians: "Just say Ho"--------
charette@edsews.EDS.COM (Mark A. Charette) (01/15/89)
Regarding Microsoft C - It specifically states in the 5.1 Update (page 54) that __STDC__ is defined as 0, with 1 meaning full conformity with the ANSI proposed standards. If we could only get them to drop the __STDC__ if the compiler doesn't conform to the full-use standards. -- Mark Charette "People only like me when I'm dumb!", he said. Electronic Data Systems "I like you a lot." was the reply. 750 Tower Drive Voice: (313)265-7006 FAX: (313)265-5770 Troy, MI 48007-7019 charette@edsews.eds.com uunet!edsews!charette
hansen@pegasus.ATT.COM (Tony L. Hansen) (01/15/89)
This is my understanding of what will be in the SVr4 compiler (according to
information which I've seen released). It will have 3 modes, selectable via
compiler options.
The default mode will be fully ANSI C conforming except for the fact that
the additional UNIX System functions will be declared within the header
files. Because of this exception, __STDC__ will be predefined to 0.
If the "fully-conforming" ANSI mode is chosen, __STDC__ will be
predefined to 1 and those extra functions will not declared.
(The 3rd mode is essentially the same as the first except that arithmetic
for unsigned integers use the old rules which are no longer true. I don't
recall the setting for __STDC__.)
Now these questions come up:
1) Should it declare the extra functions by default?
My feeling is yes. After all, this is for a UNIX System and
those functions should continue to be declared where they used
to be or else code will be broken.
2) Should it #define __STDC__ to be 1 by default?
First off, can it? Because it declares the extra functions,
does that prevent it from being a "fully conforming" ANSI
C compiler? If it weren't for those extra function declarations,
it would be indistinguishable from a "fully conforming" mode.
Perhaps it SHOULD #define __STDC__ as 1 for both modes.
3) Is the SVr4 C compiler useful with this scheme?
My feeling is yes. I can use "#ifdef __STDC__" to fully differentiate
within my code between the old K&R C and new ANSI C syntaxes.
4) Is it broken?
Well, it gives you a choice between the "fully conforming" mode
and the mode which declares those extra functions. You can easily
define an "ansicc" which does "cc -A" (or whatever the option is
called). It lets you distinguish fully between pre-ANSI mode,
ANSI mode and slightly-off-ANSI mode. Is it broken? I don't think
so.
By the way, I also reject the opinion that using -D when invoking an ANSI C
compiler:
ansicc -Dxyz
should suddenly cause __STDC__ to be undefined. (Sorry Doug, I think you're
wrong here.)
Tony Hansen
att!pegasus!hansen, attmail!tonyjv@mhres.mh.nl (Johan Vromans) (01/15/89)
From article <9369@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > Apart from screaming at MicroSoft about this brain damage, I guess we > all have now been forced to use "#if __STDC__" to survive that stupid > decision. ... which will yield a nice warning "__STDC__ not defined, treated as zero" in at least one C implementation I know. -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944
w-colinp@microsoft.UUCP (Colin Plumb) (01/16/89)
gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) wrote: > I maintain that predefining __STDC__ is a mistake, except when the > implementation conforms to the Standard (in which case __STDC__ is > necessarily preset to 1, for the current standard, or some number > greater than 1, presumably, for a future compatible standard). > There is no way you can know what use a programmer is making of > __STDC__. In fact your guess was wrong for some of the code we > have.. True, but if the programmer is really exercising the ANSI C standard, they'll know about the __STDC__ == 1 (#if __STDC__ is shorter, anyway!) and won't get caught. But if, as is very popular, they use ##ifdef __STDC__ as a switch to tell whether to use ANSI cpp-isms or Reiser tricks for token-pasting, or whether they can include prototypes, or use void *, etc., it'll work. It seems like a reasonable convention to me. -- -Colin (uunet!microsof!w-colinp)
friedl@vsi.COM (Stephen J. Friedl) (01/16/89)
In article <8470@edsews.EDS.COM>, charette@edsews.EDS.COM (Mark A. Charette) writes: > If we could only get them to drop the __STDC__ if the compiler doesn't conform > to the full-use standards. Convincing a vendor to simply drop __STDC__=0 is probably harder than it looks because it will "break" the code of those who bought the compiler the first time. Perhaps a reasonable compromise is to permit __STDC__ to be #undef-ed (on the command line, perhaps) in non-conformant mode. Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for you only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl ---------Nancy Reagan on Hawaiian musicians: "Just say Ho"--------
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/16/89)
In article <274@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) wrote: >> There is no way you can know what use a programmer is making of __STDC__. >But if, as is very popular, they use ##ifdef __STDC__ as a >switch to tell whether to use ANSI cpp-isms or Reiser tricks for >token-pasting, or whether they can include prototypes, or use void *, etc., >it'll work. What I'm telling you is, NO, it will NOT work, because there is no standard for the meaning of __STDC__ except in the context of full ANSI conformance. If an implementation can properly support WHATEVER I might choose to key on __STDC__, then it is in effect standard conforming and therefore should set __STDC__ to 1. Problems arise when a non-conforming implementation thinks it is "close enough" and consequently defines __STDC__ (whether to 0 or 1 is immaterial, since #ifdef __STDC__ is as likely to be used as the more paranoid #if __STDC__). X3J11 was quite serious in setting forth strict injunctions against name space pollution, etc. __STDC__ was specified so that program source code could have a way to determine whether it was being compiled in a known environment or in some uncontrolled one. This is a very crisp distinction. To rip off the indicator to denote some ill-defined environment simply exhibits the vendor's lack of understanding how important to the application developer strict control over the implementation environment is. __STDC__ should be considered to lie entirely within "C standard" turf, off-limits to non-standard implementations. If you need "feature flags", invent some, as is commonly done (usually, Makefiles can be configured to enable the appropriate set of feature flags for each specific target environment). You need more than a single "feature flag" anyway! One thing for sure -- I'm not buying compilers that screw this up.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/16/89)
In article <2788@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: >From article <9369@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): >> Apart from screaming at MicroSoft about this brain damage, I guess we >> all have now been forced to use "#if __STDC__" to survive that stupid >> decision. >... which will yield a nice warning "__STDC__ not defined, >treated as zero" in at least one C implementation I know. Strange implementation, but at least you can ignore such warnings. If this becomes a real problem for you, you can use #if defined(__STDC__) && __STDC__ but then there are C implementations that don't allow defined() to be used in expressions, if at all, so the next attempt is #ifdef __STDC__ #if __STDC__ but if somebody's implementation stupidly #defines __STDC__ as the symbol "almost" then you're completely out of luck. Obviously the original desire for #ifdef __STDC__ to work right is a sensible desire; it avoids the warnings you mention without causing any other problems, IF the compiler vendors would get their act together and not #define __STDC__ unless they (fully) conform to the Standard.
peter@ficc.uu.net (Peter da Silva) (01/17/89)
What is needed, then, is: #ifdef __STD_PROTO__ /* Function prototyping */ #ifdef __STD_STRING__ /* string concatenisation */ #ifdef __STD_TOKEN__ /* token pasting */ ... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
mike@arizona.edu (Mike Coffin) (01/17/89)
From article <9391@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > Problems arise when a non-conforming implementation thinks it is > "close enough" and consequently defines __STDC__ (whether to 0 or 1 > is immaterial, since #ifdef __STDC__ is as likely to be used as the > more paranoid #if __STDC__). 1) If the intent was that only conforming compilers define __STDC__, why is this loophole in the standard? I.e., why does the standard specify "1" as THE value for __STDC__? Is it too late to change things, if the wording does not correspond to the intent? 2) Why is #ifdef "as likely to be used" as #if? The latter is shorter and tests for exactly what the standard specifies; the former is longer and doesn't. It seems to me that using #ifdef for this purpose is just a bug, pure and simple. 3) I suppose there is a need to determine whether the compiler is exactly "conforming", although I'm not sure what you would do if it wasn't. But the need is far more pressing for a flag that answers the question "is this a K&R compiler or an ANSI compiler?" How do we tell the difference between a K&R compiler and an ANSI compiler that is invoked in such a way that it's nonconforming? (E.g., "cc -DFOO".) Does the standard say anything about this? Shouldn't we adopt some convention before we have chaos? 4) In view of the fact that "#ifdef __STDC__" doesn't tell us anything, according to the standard (as I understand it), what is wrong with using it to indicate "rough ANSI compliance"? -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
geoff@warwick.UUCP (Geoff Rimmer) (01/17/89)
In article <274@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >It seems like a reasonable convention to me. > -Colin (uunet!microsof!w-colinp) ^^^^^^^^ Well he *would* say that, wouldn't he? :-) :-) Geoff ------------------------------------------------------------ Geoff Rimmer, Computer Science, Warwick University, England. geoff@uk.ac.warwick.emerald "Why don't we go out for one NON-alcoholic drinkie?" "Such as?" "Vodka" - Filthy Rich and Catflap, 1986. ------------------------------------------------------------
peter@ficc.uu.net (Peter da Silva) (01/17/89)
In article <9416@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <2779@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >What is needed, then, is: > > #ifdef __STD_PROTO__ /* Function prototyping */ > > #ifdef __STD_STRING__ /* string concatenisation */ > > #ifdef __STD_TOKEN__ /* token pasting */ > That's fine; get compiler vendors to agree on a useful set. I can't do that. Only someone like X3J11 could push it through. By the by, some people are claiming that putting '-DFOO' on the command line makes the compiler non-conforming. Doesn't that make __STDC__ pretty useless? Have you looked at the news sources, lately? > X3J11 decided not to authorize official "levels" of conformance > to the Standard; I suspect this is a mistake. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
seg@smsdpg.uu.net (Scott Garfinkle) (01/17/89)
From article <9391@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > ... > One thing for sure -- I'm not buying compilers that screw this up. Better not get AT&T SysV R4.0 when it appears, then. They set __STDC__ to zero to indicate that you're using their ANSI-type compiler with the ANSI stuff turned off. (At least, that is the plan, according to the presentation in their Software Developers' Conferences.) Scott E. Garfinkle SMS Data Products Group, Inc. uunet!smsdpg!seg
ftw@masscomp.UUCP (Farrell Woods) (01/17/89)
In article <8731@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >1) If the intent was that only conforming compilers define __STDC__, > why is this loophole in the standard? I.e., why does the standard > specify "1" as THE value for __STDC__? Is it too late to change > things, if the wording does not correspond to the intent? I think this was explained before. It is a mechanisim to allow future revisions to the standard. #if (__STDC__ == 1) will mean that this compiler (fully) conforms to what is currently the pANS. If a future standard should emerge, then the (fully) conforming compilers for that standard will set __STDC__ to 2, etc. Mr. Gwyn will correct me if I'm wrong ;-) >2) Why is #ifdef "as likely to be used" as #if? The latter is shorter > and tests for exactly what the standard specifies; the former is > longer and doesn't. It seems to me that using #ifdef for this > purpose is just a bug, pure and simple. Other have indicated that some compilers produce warnings if a undefined constant appears in a #if expression. This is weak, though. #ifdef __STDC__ is supposed to answer the yes/no question of whether this is a fully conforming compiler. #if __STDC__ will of course work, but it answers a slightly different question. >3) I suppose there is a need to determine whether the compiler is > exactly "conforming", although I'm not sure what you would do if it > wasn't. But the need is far more pressing for a flag that answers > the question "is this a K&R compiler or an ANSI compiler?" How do > we tell the difference between a K&R compiler and an ANSI compiler > that is invoked in such a way that it's nonconforming? (E.g., > "cc -DFOO".) Does the standard say anything about this? Shouldn't > we adopt some convention before we have chaos? I don't know if I quite understand the question. I don't believe that there is a "strict" interpretation of K&R; I suspect that is why we have X3J11 to help sort this out. If I invoke a conforming compiler with "cc -DFOO", but my program has #ifdef __STDC__ in it, how does this break conformance? >4) In view of the fact that "#ifdef __STDC__" doesn't tell us > anything, according to the standard (as I understand it), what is > wrong with using it to indicate "rough ANSI compliance"? That's the whole point: if vendors abuse __STDC__, then its meaning becomes eroded. __STDC__ only tell us something useful if vendors of non-conforing compilers respect its stated meaning. Obviously, X3J11 doesn't own the name "C" as a trademark, as the DoD does "Ada". Those of us who use C, and those who took their time to hammer out the pANS can only hope that vendors do not abuse __STDC__. When they do, we can raise a stink and threaten not to buy their compilers, etc., but we can't sue them. Here's another thing to think about. If each vendor that "almost" has all features of the pANS and decides to #define __STDC__ 0, how can my program figure out which subset of the pANS is in effect if I take the program from compiler A to compiler B? It really is a all-or-nothing shot. -- Farrell T. Woods Voice: (508) 692-6200 x2471 MASSCOMP Operating Systems Group Internet: ftw@masscomp.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/18/89)
In article <8731@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >1) If the intent was that only conforming compilers define __STDC__, > why is this loophole in the standard? I.e., why does the standard > specify "1" as THE value for __STDC__? Is it too late to change > things, if the wording does not correspond to the intent? The wording does reflect the intent. Rather than "__STDC__ is defined as some nebulous thing", the proposed Standard says what it is defined as, for this edition of the Standard. (Presumably it would have other values in revisions of the Standard.) The Standard is obviously unable to specify anything about __STDC__ for a non-conforming implementation, because by definition such implementations do not obey the Standard! >2) Why is #ifdef "as likely to be used" as #if? The latter is shorter > and tests for exactly what the standard specifies; the former is > longer and doesn't. It seems to me that using #ifdef for this > purpose is just a bug, pure and simple. Either form tests "true" with a standard-conforming implementation. It SHOULD be the case that either form tests "false" with non-conforming implementations. However, there are known non-conforming implementations that complain about "#if __STDC__" unless __STDC__ is defined as a numeric expression (which it isn't, in those implementations). Therefore a programmer may prefer "#ifdef __STDC__" to distinguish between Standard- conforming and non-conforming environments. But is non-conforming environments decide to define __STDC__, this doesn't work either. >3) I suppose there is a need to determine whether the compiler is > exactly "conforming", although I'm not sure what you would do if it > wasn't. But the need is far more pressing for a flag that answers > the question "is this a K&R compiler or an ANSI compiler?" How do > we tell the difference between a K&R compiler and an ANSI compiler > that is invoked in such a way that it's nonconforming? (E.g., > "cc -DFOO".) Does the standard say anything about this? Shouldn't > we adopt some convention before we have chaos? I don't know what you mean by a "K&R compiler". Existing UNIX compilers do not conform to either K&R or the pANS. From my perspective, the MOST important distinction is between C environments that follow the Standard (in which case I know EXACTLY what to expect) and ones that don't. The latter category is just as messed up as it has ALWAYS been, and no single test is sufficient to untangle THAT mess. However, we should adhere very strictly to the use of __STDC__ to distinguish between the well-defined case and the myriad of random implementations. Dragging __STDC__ into the morass merely ruins its utility; it doesn't help the user of an uncontrolled C environment to determine anything reliable. >4) In view of the fact that "#ifdef __STDC__" doesn't tell us > anything, according to the standard (as I understand it), what is > wrong with using it to indicate "rough ANSI compliance"? I've explained that above. "Rough ANSI compliance" is meaningless and useless to the portable application programmer. "Strict ANSI compliance", on the other hand, is a meaningful notion of considerable utility to the programmer. In order for it to HAVE this utility, though, we need the symbol __STDC__ reserved for making the distinction.
mike@arizona.edu (Mike Coffin) (01/18/89)
From article <9405@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): >>3) I suppose there is a need to determine whether the compiler is >> exactly "conforming", although I'm not sure what you would do if it >> wasn't. But the need is far more pressing for a flag that answers >> the question "is this a K&R compiler or an ANSI compiler?" How do >> we tell the difference between a K&R compiler and an ANSI compiler >> that is invoked in such a way that it's nonconforming? (E.g., >> "cc -DFOO".) Does the standard say anything about this? Shouldn't >> we adopt some convention before we have chaos? > > I don't know what you mean by a "K&R compiler". Existing UNIX compilers > do not conform to either K&R or the pANS. From my perspective, the MOST > important distinction is between C environments that follow the Standard > (in which case I know EXACTLY what to expect) and ones that don't. The > latter category is just as messed up as it has ALWAYS been, and no > single test is sufficient to untangle THAT mess. However, we should > adhere very strictly to the use of __STDC__ to distinguish between the > well-defined case and the myriad of random implementations. Dragging > __STDC__ into the morass merely ruins its utility; it doesn't help the > user of an uncontrolled C environment to determine anything reliable. Thanks for the answers, most of which I'll buy. This one I still have trouble with. I still say, the most important distinction is between C environments that "essentially" follow K&R and those that "essentially" follow pANS. I will grant you that "essentially" is an imprecise term, but this is still the important question. (I can't define a K&R compiler, but I know one when I see it :-) Previous implementations of C adhered more or less to one (de facto) standard, future ones will adhere more or less to pANS. In a lot of situations I want to know which. E.g. * should I use function prototypes? * can I assume that parenthesis will control evaluation order? * how do I splice tokens? * should I include <varargs> or <stdargs>? These are practical problems, for which I see no solution at the moment. Strict compliance isn't something that buys me much. I don't have much use for a flag that will get turned off if the compiler is invoked with "cc -DDEBUG". Where will I use it? -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
mike@arizona.edu (Mike Coffin) (01/18/89)
From article <358@masscomp.UUCP>, by ftw@masscomp.UUCP (Farrell Woods): > If I invoke a conforming compiler with "cc -DFOO", but my program > has #ifdef __STDC__ in it, how does this break conformance? If "cc -DFOO" has the effect of providing of predefining FOO, then it does not provide a conforming compilation environment: the program's name space has been polluted. So I assume that __STDC__ will not be defined in such cases. Do you think this should be an exception? If so, do you have any other exceptions in mind? -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/18/89)
In article <8741@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >I still say, the most important distinction is between C environments >that "essentially" follow K&R and those that "essentially" follow pANS. Now, that's an argument I don't buy. The pANS is essentially a superset of "K&R C" as we're loosely using the term here. So testing __STDC__ does not make the proper distinction. In fact there is no easy way to test with #ifs etc. what kind of non-Standard conforming implementation you're dealing with. That's simply a historical fact of life, with which most of us who port C code have had to figure out ways to cope. __STDC__ was never intended to help with that, because it can't. >These are practical problems, for which I see no solution at the >moment. Yes, and since __STDC__ is not defined at all in most existing C environments using it is no solution either, except that the answers to your "is this ANSI C feature available" questions are all supposed to be "yes" for __STDC__ and "who knows?" for non-__STDC__. >Strict compliance isn't something that buys me much. I don't have >much use for a flag that will get turned off if the compiler is >invoked with "cc -DDEBUG". Where will I use it? I consider the "cc -DDEBUG" issue negotiable, since it takes an explicit user action to violate the standard constraint, so perhaps it is appropriate to place the burden of responsibility on the user in such a case. For example, the compiler documentation might say: "Although __STDC__ is always 1, if you predefine macros then you do not have a Standard-conforming implementation, so beware!"
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/18/89)
In article <2779@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >What is needed, then, is: > #ifdef __STD_PROTO__ /* Function prototyping */ > #ifdef __STD_STRING__ /* string concatenisation */ > #ifdef __STD_TOKEN__ /* token pasting */ That's fine; get compiler vendors to agree on a useful set. X3J11 decided not to authorize official "levels" of conformance to the Standard; it is a pure binary choice (for which __STDC__ is supposed to provide one bit of information, not several bits as some vendors appear to have decided).
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (01/18/89)
In article <8742@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >From article <358@masscomp.UUCP>, by ftw@masscomp.UUCP (Farrell Woods): >> If I invoke a conforming compiler with "cc -DFOO", but my program >> has #ifdef __STDC__ in it, how does this break conformance? > >If "cc -DFOO" has the effect of providing of predefining FOO, then it >does not provide a conforming compilation environment: the program's >name space has been polluted. So I assume that __STDC__ will not be >defined in such cases. Do you think this should be an exception? If >so, do you have any other exceptions in mind? I really find this to be a highly bogus argument. There should be no difference between 'cc -DFOO ...' and adding a '#define FOO' at the very first line. Remember that it is the USER who polluted the namespace. Every variable or macro definition in a program is 'namespace pollution'. I would argue that the important difference is that the user selected the option to add the definition for FOO. Adding new reserved words, such as 'near' or 'far' or 'fortran' is different. Those aren't exceptions. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"UNIX doesn't have bugs, InterNet: jfh@rpp386.Dallas.TX.US | UNIX is a bug." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
guy@auspex.UUCP (Guy Harris) (01/18/89)
>The Standard is obviously unable to specify anything about __STDC__ >for a non-conforming implementation, because by definition such >implementations do not obey the Standard! Would putting a recommendation in the Rationale that non-conforming implementations not define __STDC__ at all help? >I've explained that above. "Rough ANSI compliance" is meaningless >and useless to the portable application programmer. "Strict ANSI >compliance", on the other hand, is a meaningful notion of considerable >utility to the programmer. In order for it to HAVE this utility, >though, we need the symbol __STDC__ reserved for making the >distinction. How meaningful is its antithesis? "Strict ANSI non-compliance" could mean anything from "they define 'ferror' as a macro in <stdio.h>" to "this is really a Pascal compiler, and we played a cruel joke on the customer by selling it as a non-compliant C compiler." In other words, I can sort of see what goes in between "#if __STDC__" and "#endif", as long as there's no "#else", say, at that level between them; if you stick a "#else" in there at that level, what goes between it and "#endif"? If the the question really can't be answered meaningfully, I don't see that "#if __STDC__" is a useful test; the only useful tests I could see would be something such as #if __STDC__ == 2 #define NOALIAS noalias #elif __STDC__ == 1 #define NOALIAS #endif once the second ANSI C standard comes out after all the problems noted with "noalias" have been solved :-). Now one form of "strict ANSI non-compliance" (i.e., the negation of "strict ANSI compliance") that could be useful would be that exhibited by an implementation that conforms to ANSI C except for POSIX items that might get in the way. This would include declarations of functions, and definition of macros, that POSIX mentions in connection with some include file also mentioned in ANSI C. For instance, <stdio.h> would probably define "ferror" as a macro. Doing so breaks ANSI compliance, as I understand it; however, doing so is also quite useful to writers of portable applications, with "portable" meaning "portable to POSIX-conformant systems" rather than "portable to ANSI C-conformant systems. POSIX does not, as I remember, require ANSI C conformance; thus, you might want to write applications that are portable to POSIX-conformant systems that can be built and run both on ANSI C-conformant and "many" ANSI C-non-conformant systems. Yes, I know that in some deep sense they can't rely on any particular part of the ANSI C-non-conformant systems' C implementations; however, this nonwithstanding, such applications will be written *anyway*, since the writers may not be able to postpone paying their mortgage bills until such time as major vendors come out with their ANSI C compilers. By and large, they will probably assume "recent PCC" C, and hope for the best. Given that, for example, I could see portable code being written ("portable" meaning "portable to ANSI-conformant POSIX-conformant systems, and most POSIX-conformant systems that implement 'recent PCC' C"), with some #ifdef controlling the use of function prototypes or any of a number of other things. One possibility for these #ifdef might be specific names for particular functions; unfortunately, there's no standard for those names, so the writer can't assume something and hope for the best. Unfortunately, alternatives involving __STDC__ have the problems you list. I don't think there's anything that POSIX defines that says "this implementation is ANSI C, with the exception of this specified list of extra goobers in the namespace"; if there isn't, it's too late to fix it in POSIX. The best I see that could be done here is to make a strong recommendation that POSIX vendors define __ANSI_C_EXCEPT_FOR_POSIX_STUFF__ (or some other specified name) to match what __STDC__ would have been defined as had the "allow POSIX stuff" flag not been given to the compiler.
mike@arizona.edu (Mike Coffin) (01/19/89)
From article <11236@rpp386.Dallas.TX.US> (John F. Haugh II): > I really find this to be a highly bogus argument. There should be > no difference between 'cc -DFOO ...' and adding a '#define FOO' at the > very first line. Perhaps this particular example of nonconformance can be dealt with, but please listen to my general argument. Minor exceptions to strict compliance to pANS will be common. Mr. Guin says, and he has convinced me, that __STDC__ should only be used when the compiler is a completely conforming ANSI compiler. Fine. There are probably some cases where __STDC__ will be useful, although I haven't been able to think of one. All I'm saying is that there is a need for some flag that indicates "rough ANSI compliance"; i.e., support for the NEW and INCOMPATIBLE features that were introduced in pANS. It is true that we can each invent such flags for ourselves; it really isn't a big deal. But it would save a little grief if everyone would agree on something. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
mike@arizona.edu (Mike Coffin) (01/19/89)
Oops. I wrote
> Mr. Guin says
when I meant Mr. Gwyn. Sorry.
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike
Tucson, AZ 85721 (602)621-2858sue@hpclsue.HP.COM (Sue Meloy) (01/19/89)
To me, the question boils down to name space and extensions. I feel __STDC__ should definitely not be defined unless all syntax of the ANSI standard is allowed (prototypes, token pasting, ...). Although AT&T apparently thinks differently, I also feel that __STDC__ should not be defined if the semantics are different from ANSI. But, for syntax extensions and name space pollution, I do feel that it may be reasonable to define __STDC__. In particular, POSIX requires additional names that would pollute a strict ANSI name space. Is it reasonable to say that __STDC__ should not be defined in a POSIX implementation? As for syntax extensions (accepted silently), no strictly-conforming program should be affected. Programs that use the extension would not receive a diagnostic, rendering the implementation non-standard, so theoretically __STDC__ should not be defined. Would defining __STDC__ in either of these situations cause problems? If not, is it OK to define it to 1, or should it be 0? Doug, you mentioned that one implementation "guessed wrong" about your intent for using __STDC__. Could you elaborate on the problems it caused?
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/19/89)
In article <860@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >Would putting a recommendation in the Rationale that non-conforming >implementations not define __STDC__ at all help? Well, it might have been a good idea, but I'm sure the X3J11 Redactor (who advised AT&T to #define __STDC__ 0) would object, and perhaps the Rationale editor wouldn't agree to do it unless so directed by committee vote. Also I don't think any additional editorial work is planned; the proposed Standard and Rationale have been submitted to X3 already. >if you stick a "#else" in there at that level, what goes between it >and "#endif"? Whatever is already going on in the existing pre-ANSI C implementation. The reason we needed a standard was that this was pretty much a random approximation to what K&R seemed to be saying, plus various additional inventions done wildly differently by different implementors. There is no logical way to stretch anything from the new (proposed) Standard to cover the existing behavior, and I think it is a mistake to try. >If the the question really can't be answered meaningfully, I don't see >that "#if __STDC__" is a useful test; the only useful tests I could see >would be something such as > #if __STDC__ == 2 > #define NOALIAS noalias > #elif __STDC__ == 1 > #define NOALIAS > #endif >once the second ANSI C standard comes out after all the problems noted >with "noalias" have been solved :-). That is indeed one possible use for values of __STDC__. The problem is NOT in the __STDC__==1 (or ==2, etc.) domain; it's in the unstandardized domain, for which __STDC__ simply does not help -- it's not even defined in most of the environments I currently have to port code to, and having it defined as 0 would help me not one bit. I do rely on __STDC__ to determine whether to use <stdarg.h> or <varargs.h>, for example. That doesn't mean that <varargs.h> necessarily exists in a non-standard environment, but if it doesn't I can probably cons up an implementation and add it to the local extensions to the environment. The point is that I am supposed to be able to RELY on <stdarg.h> in an environment that indicates that it is standard-conforming. The question is, how do I test in my source code for that, using __STDC__? I e-mailed a detailed examination of the alternatives to Dave Prosser of AT&T; the bottom line is that a PARANOID programmer is advised to write #ifdef __STDC__ #if __STDC__ > 0 #define MY_STDC_INDICATOR 1 #endif #endif then use MY_STDC_INDICATOR instead of __STDC__, if he is unable to trust the vendors to leave __STDC__ alone. Even that won't defend against really stupid preemption of __STDC__ by the vendors, but I was unable to figure out ANY guaranteed meaningful use of __STDC__ in such a case. On the implementor's side, assuming he wishes to support use of __STDC__ in SOME useful way by applications, his best strategies (in non-conforming mode) turn out to be either: leave __STDC__ undefined or define it as 0. (Other choices were all clearly suboptimal.) Either of these choices would be acceptable for paranoid programs (which would use the technique described above as the best bet against the widest range of vendor strategies). However, against simpler programming techniques such as #ifdef __STDC__ or #if __STDC__ one or another vendor choice (for the non-conforming mode) would be better than the other. It should be noted that the second program test just given fails in some existing C implementations ("use of undefined symbol in preprocessing expression"), so in fact many programmers may be tempted to use the first form. If they do so, then __STDC__ defined as 0 causes the wrong branch to be taken in compiling the source code; whether or not that is benign depends on which "ANSI C" features the code is trying to exploit and whether or not they are available in the non-conforming case. Apparently some vendors think that such conditionalization will always be done to take advantage of features that are available even in their __STDC__- equal-to-0 case, but I dispute that. (I gave Dave a simple example to the contrary.) >Now one form of "strict ANSI non-compliance" (i.e., the negation of >"strict ANSI compliance") that could be useful would be that exhibited >by an implementation that conforms to ANSI C except for POSIX items that >might get in the way. There weren't supposed to be any of these! As inheritor of the role of 1003.1/X3J11 liaison, I'm painfully aware of that; read on... The main problem seems to be that vendors want to include their old extra UNIX cruft in <stdio.h> without requiring their customers to use a different form of compilation from the ANSI C mode. Even 1003.1 wants to do this. I don't think that is even possible. So then the question becomes, how to most readily make one compiler serve both environments AND the new POSIX environment. That really requires two bits of information to properly select all possible cases. ANSI C __STDC__ is apparently being relied on to switch on the "ANSI C or not" bit. _POSIX_SOURCE, a late invention to try to resolve the name space conflicts in standard headers that define things for both ANSI C and POSIX, was specified backward from what X3J11 had recommended; consequently vendors such as AT&T have decided that it is not suitable for use as the other selection bit and are trying to overload __STDC__ for this. _POSIX_SOURCE, specified as being supplied by the APPLICATION, not the implementation, was specified as turning OFF POSIX-permitted extensions, but what was really needed was a way to turn ON ANSI C-prohibited extensions, which is not at all the same thing, and in any event the vendors don't want to tell their customers to #define _POSIX_SOURCE in order for their existing code to compile. The simplest solution would have been: cc # backward-compatible sloppy UNIX mess version acc # ANSI-conforming version pcc # POSIX- and ANSI-conforming version fcc # like "pcc" but with extra ANSI-prohibited stuff. Presumably all four would predefine various secret __names then invoke common compiler passes, perhaps with additional flags to turn on Reiserisms in cpp etc. What I would have for the two names known to the programmer in each of the four cases are: cc __STDC__ not defined acc __STDC__==1 pcc __STDC__==1 fcc __STDC__ not defined I think AT&T has in mind the use of __STDC__==0 in the "fcc" case instead of coming up with their own secret symbols, and merging "cc" and "fcc" together into one case, and "acc" and "pcc" into a second case. Given the _POSIX_SOURCE botch such a merged "acc/pcc" would still have to require applications to #define _POSIX_SOURCE, not only to turn off unconstrained POSIX extensions, but also to turn ON POSIX conformance. (That's the "compromise" position as it emerged from the liaison work; I'll be the first to admit that it is only technically a solution to the conflict, not practically.) Thus I don't think it advisable to actually merge the four cases into two. >For instance, <stdio.h> would probably define "ferror" as a macro. >Doing so breaks ANSI compliance, as I understand it; ... NO! Nearly all ANSI C functions can be implemented as macros, IF they are "safe" macros (evaluate their argument exactly once) AND there is also a genuine function in the C library (in case the programmer wants to use a pointer to it). >... with "portable" meaning "portable to POSIX-conformant systems" >rather than "portable to ANSI C-conformant systems. But POSIX-conformant systems are supposed to be ANSI C-conformant also, unless they are specifically advertised as "Common Usage C" versions. This means that a (POSIX+ANSI C)-conformant implementation CANNOT declare fdopen() in <stdio.h> as default behavior. Given the way _POSIX_SOURCE ended up being specified, any POSIX application that requires fdopen() MUST #define _POSIX_SOURCE before including <stdio.h>. (In fact, I would argue that ALL applications HAVE TO #define _POSIX_SOURCE in order to meet the letter of the POSIX spec.) It would be nice if one of the supported compiler invocations ("pcc" in my list above) would predefine _POSIX_SOURCE (which ANSI C DOES allow) so that one wouldn't need to edit source files to accomplish this (and would only need to change the definition of "CC" in one's master Make.config). That would be far more useful than the apparent choice of compilation environments AT&T seems to be heading toward. >POSIX does not, as I remember, require ANSI C conformance; ... What it does require is that any implementation that doesn't conform to the C Standard shall clearly so state. The two choices are: C Standard Language-Dependent System Support Common Usage C Language-Dependent System Support (Technically, the use of cross-reference to sections of the C Standard is pointless unless the POSIX implementation is ANSI C conformant, because the C Standard does not constrain non-conforming implementations IN ANY WAY. But this is just a legality and was not actually intended to be interpreted that way.) >One possibility for these #ifdef might be specific names for particular >functions; unfortunately, there's no standard for those names, so the >writer can't assume something and hope for the best. Unfortunately, >alternatives involving __STDC__ have the problems you list. I don't >think there's anything that POSIX defines that says "this implementation >is ANSI C, with the exception of this specified list of extra goobers in >the namespace"; if there isn't, it's too late to fix it in POSIX. No, there's nothing like that. Only _POSIX_SOURCE even comes close. >The best I see that could be done here is to make a strong >recommendation that POSIX vendors define >__ANSI_C_EXCEPT_FOR_POSIX_STUFF__ (or some other specified name) to >match what __STDC__ would have been defined as had the "allow POSIX >stuff" flag not been given to the compiler. Practially ANY de facto standard not involving __STDC__ would be fine so far as I'm concerned. As it stands, we have no satisfactory solution. I suggest that "pcc" mean "POSIX and almost ANSI C conforming with the symbol _POSIX_SOURCE predefined for your convenience" (the only deviation from ANSI C conformance being the extra POSIX stuff in the standard headers) and that "acc" mean "ANSI C conforming". "cc" should mean "our closest approximation to the cc you were already using, except for possible compatible extensions". I don't think there is any practical need for a "POSIX and ANSI C conforming" invocation of the compiler; "pcc" should be good enough. It's really unfortunate that 1003.1 didn't straighten out more of the name space problems historical UNIX has had.
jgm@k.gp.cs.cmu.edu (John Myers) (01/19/89)
In article <9415@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I consider the "cc -DDEBUG" issue negotiable, since it takes an >explicit user action to violate the standard constraint, so perhaps >it is appropriate to place the burden of responsibility on the user >in such a case. For example, the compiler documentation might say: >"Although __STDC__ is always 1, if you predefine macros then you do >not have a Standard-conforming implementation, so beware!" By the same argument, "cc -standard-extensions" (which can be thought of as prepending "#define asm __builtin_asm", "#define unix" and other such stuff to the source file) could legitimately have __STDC__ predefined. The fact that most implementations will use something like the absence of the switch "-strict-ansi" to do this is somewhat irrelevent. Namespace pollution can hardly be considered grounds for undefining __STDC__. As has been mentioned before, __STDC__ is useless for dealing with pollution. There's no strategy one can use on the other side of the #else--either one is going to get burned or one is not. With such things as token-pasting, <stdarg.h>, and function prototypes, one can use traditional methods (Reiser hacks, <varargs.h>, and old-style declarations) on the other side of the #else and have an extremely good chance of its working. I agree that defining __STDC__ to be 0 is a crock. (On the issue of libraries, a compiler could do the same thing as "gcc -ansi -pedantic" and claim to be a "conforming freestanding implementation." Who says there are no subsets of conformance?) -- _.John G. Myers Internet: John.Myers@cs.cmu.edu (412) 268-5655 LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up "The datefield parameter is a six byte, null-terminated string encoding the UNIX date in base 64." -- Andrew Message System documentation. --
guy@auspex.UUCP (Guy Harris) (01/19/89)
In article <860@auspex.UUCP> guy@auspex.UUCP (Guy Harris) demonstrates that one should not operate heavy machinery while drowsy, by writing: >How meaningful is its antithesis? "Strict ANSI non-compliance" could >mean anything from "they define 'ferror' as a macro in <stdio.h>" to ^^^^^^ when he meant >mean anything from "they define 'fileno' as a macro in <stdio.h>" to ^^^^^^ and writing >include file also mentioned in ANSI C. For instance, <stdio.h> would >probably define "ferror" as a macro. Doing so breaks ANSI compliance, ^^^^^^ when he meant >probably define "fileno" as a macro. Doing so breaks ANSI compliance, ^^^^^^ since "ferror" is part of ANSI C's name space, but "fileno" isn't but *is* part of POSIX's name space (and is defined as a macro in all the UNIX implementations I know of). Sigh.
jagardner@watmath.waterloo.edu (Jim Gardner) (01/19/89)
In article <8742@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes:
:From article <358@masscomp.UUCP>, by ftw@masscomp.UUCP (Farrell Woods):
:> If I invoke a conforming compiler with "cc -DFOO", but my program
:> has #ifdef __STDC__ in it, how does this break conformance?
:
:If "cc -DFOO" has the effect of providing of predefining FOO, then it
:does not provide a conforming compilation environment: the program's
:name space has been polluted. So I assume that __STDC__ will not be
:defined in such cases. Do you think this should be an exception? If
:so, do you have any other exceptions in mind?
You're viewing the -DFOO as changing the compiler. Alternatively, you can
view it as an option that specifies the C source input, inserting a
"#define FOO" and "#line 1" lines before the first line of the
"source file". The translation environment is not changed, but the input
source is specified in a peculiar way.gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/19/89)
In article <2797@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >By the by, some people are claiming that putting '-DFOO' on the command >line makes the compiler non-conforming. Doesn't that make __STDC__ >pretty useless? Have you looked at the news sources, lately? I think I was the one who first advanced that argument; however I now think that it isn't necessary to enforce that. It all depends on whether you consider such an invocation of the compiler to make the IMPLEMENTATION or the APPLICATION the definer of the symbol. Technically by the ANSI C spec there is no alternative but to consider this a definition by the implementation. However, if "cc -c -DFOO source.c" is viewed as a convenient abbreviation for essentially echo '0a/#define FOO 1\n/\nw\nq' | sam -d source.c cc -c source.c echo '1d' | sam -d source.c then it could be claimed to be an application definition. That's kind of cheating, but it's an undoubted convenience so it would be reasonable to take that approach. >> X3J11 decided not to authorize official "levels" of conformance >> to the Standard; >I suspect this is a mistake. I don't think so. Languages that HAVE had "levels" have shown that having them is a mistake.
donn@hpfcdc.HP.COM (Donn Terry) (01/20/89)
I'm going to start a new sequence on the _POSIX_SOURCE part of this discussion. I need to respond to some of Doug's remarks in that area, but I don't want to attach it to this discussion. Donn Terry Chair, IEEE 1003.1
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/20/89)
In article <12570003@hpclsue.HP.COM> sue@hpclsue.HP.COM (Sue Meloy) writes: >But, for syntax extensions and name space pollution, I do feel that it >may be reasonable to define __STDC__. In particular, POSIX requires >additional names that would pollute a strict ANSI name space. Is it >reasonable to say that __STDC__ should not be defined in a POSIX >implementation? Hi, Sue! That's a tough question, because the intention was for an implementation to readily be simultaneously ANSI C conforming and POSIX conforming. Unfortunately, as I discussed here recently, it wasn't specified quite right, so simultaneous conformance, while technically possible, isn't very helpful (since it forces applications to have to do something special to get at some of the POSIX names). Because of this intention, it would be reasonable to have __STDC__ defined as 1 in a POSIX implementation that conformed to ANSI C in every way except for the additional (constrained) names required by POSIX also being visible upon including the standard headers. My current opinion is that in such a case the implementation should probably also predefine _POSIX_SOURCE, but counterarguments can be made to that. (For example, if an application DOES define this symbol itself (as indicated by 1003.1), differently from the implementation, the compiler would squawk.) A very practical question for implementors is whether a C Standard validation test can "gig" them for providing the POSIX extensions in the standard headers. I think the answer to that is very clear: Yes, it can and should. Therefore there needs to be some way to invoke the compiler in both a "pure ANSI (plus allowed extensions)" mode and an "almost ANSI but with POSIX extensions as well" mode. People porting code to such an environment should be advised that the default POSIX mode of invoking the compiler is not ANSI C conformant, but only because of the additional identifiers in the standard headers required by 1003.1, and that if they really need guaranteed C Standard conformance, they need to invoke the other flavor of the compiler. I don't think that defining __STDC__ as 0 is helpful, unless there is some "gentleman's agreement" about what that means (which seems unlikely). >As for syntax extensions (accepted silently), no strictly-conforming >program should be affected. Programs that use the extension would not >receive a diagnostic, rendering the implementation non-standard, so >theoretically __STDC__ should not be defined. Yes, where the C Standard requires a diagnostic, failure to produce one renders the implementation non-conforming. (Section 2.1.1.3.) >Would defining __STDC__ in either of these situations cause problems? To me as an application developer, the important use of __STDC__ is to conditionalize source code so that one branch of the condition has a guaranteed environment available (namely, that specified in the Standard). The other branch is just as bad as it always was. There are extensions which are "transparent", since as you say no strictly-conforming code (which is what one would put into the __STDC__ "true" branch) could be affected by them. For example, adding a __near type qualifier would be such an extension. I see no reason to consider such an implementation as PRACTICALLY non-conforming, so __STDC__ should be 1 if all extensions fall into this category, even though the implementation is not TECHNICALLY a conforming one. So far as any reasonable use of __STDC__ goes, it is IN EFFECT a Standard-conforming implementation, so "lying" about it with __STDC__ in this case can do no practical harm. >If not, is it OK to define it to 1, or should it be 0? __STDC__==0 tells me NOTHING. __STDC__==1 tells me that insofar as strictly-conforming code goes, the implementation will "accept" it (i.e. successfully translate and execute it). That is what I need to know. >Doug, you mentioned that one implementation "guessed wrong" about >your intent for using __STDC__. The assumption was that the __STDC__ tester would care about such things as prototypes and variadic-function support, but not about extra names usurped by the implementation from the application's name space. I actually want to ensure that the name space is not polluted, so I can do things like #include <stdio.h> #if __STDC__ /* whatever */ /* "fdopen" is my natural name for the quantity and what I would like to see when I'm debugging */ FONTDESC *fdopen(const char *fontname); /* This function is MINE! I want to call it "fdopen". */ #else /* Just in case we're dealing with UNIX/POSIX etc.: */ #define fdopen my_fdopen /* best of a bad situation */ FONTDESC *fdopen(/*const char *fontname*/); /* But I'll settle for "my_fdopen" if pressed. */ #endif ... { FONTDESC *fd = fdopen("Courier"); ... } Note that if the __STDC__ test results in "true" in a UNIX/POSIX environment, this code will fail to compile. It would have been even worse if it had had conformable type to the function declared in <stdio.h> but radically different semantics! If there seems to evolve a general agreement that POSIX implementations are going to define __STDC__ as 1 even though there are a handful of extra names defined in the headers, then I'll simply avoid using those names even though they may be what I wanted to use myself. At least I know what those extra names ARE. I don't think we want to extend that to OTHER such implementation extensions in standard headers, though, because then I would not know what to expect when I include a standard header and would have to give up entirely on the "clean name space" guarantee that I find so valuable. IEEE Std 1003.1 may deserve an exception simply because it had attempted liaison with X3J11 on this (even though it was botched).
mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) (01/20/89)
In article <2797@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >By the by, some people are claiming that putting '-DFOO' on the command >line makes the compiler non-conforming. I do not think that the -DFOO on the command line should invalidate the __STDC__ flag. Think of it this way: the -DFOO was specified by the user, not the compiler itself, therefore, it should be allowed. How would this be different from the user specifying #define FOO on the first line of the compilation unit? Unless, of course, the user is not allowed to corrupt the namespace of the compiler either, which would make using the compiler at all a non-portable application. (More :-)'s than you can imagine.) By the same token, the user could specify -D__STDC__ on the command line to the C compiler. That would not necessarily make the compiler being used an ANSI C conforming compiler... -- Mark H. Colburn "They didn't understand a different kind of NAPS International smack was needed, than the back of a hand, mark@jhereg.mn.org something else was always needed."
peter@ficc.uu.net (Peter da Silva) (01/20/89)
If you really want to survive __STDC__==0, then here's a workable solution... (1) Use "#if __STDC__" throughout. (2) AT the beginning of your program, put this: #ifndef __STDC__ #define __STDC__ 0 #endif This will mean you will always have __STDC__ defined as 0 or 1. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
rml@hpfcdc.HP.COM (Bob Lenk) (01/20/89)
> The problem is NOT in the __STDC__==1 (or ==2, etc.) domain; > it's in the unstandardized domain, for which __STDC__ simply > does not help I agree, but I'd go one step further. In practice the X3J11 work has made the situation where __STDC__ is not defined worse. Before X3J11 there was certainly chaos, but there were various assumptions that generally held. As X3J11 has defined new features that violate those assumptions and implementors provide them piece-meal that chaos has gotten more complex. This is especially true if __STDC__ can't be defined whenever the namespace is polluted, because that's such a common and useful situation which won't go away with pre-ANSI compilers. > >Now one form of "strict ANSI non-compliance" (i.e., the negation of > >"strict ANSI compliance") that could be useful would be that exhibited > >by an implementation that conforms to ANSI C except for POSIX items that > >might get in the way. > > There weren't supposed to be any of these! As inheritor of the role > of 1003.1/X3J11 liaison, I'm painfully aware of that; read on... > > The main problem seems to be that vendors want to include their old > extra UNIX cruft in <stdio.h> without requiring their customers to > use a different form of compilation from the ANSI C mode. It seems to me that a <stdio.h> defining non-ANSI symbols results in "strict ANSI non-compliance" whether or not a separate compilation mode was used. The only ways for 1003.1 to have stayed within the strict ANSI bounds would have to move things like fileno() out of <stdio.h> or to rename them to something like __fileno(). Since the 1003.1 goals (like X3J11's) included following existing practice, this wasn't realistic. At this point 1003.1 seems to be in a "Catch 22" situation. Folks want something specified by the compiler rather than the application, but then they claim that a compiler that usurps the namespace must not define __STDC__. > _POSIX_SOURCE, a late invention to try to resolve the name space > conflicts in standard headers that define things for both ANSI C and > POSIX, was specified backward from what X3J11 had recommended; I don't recall any recommendation from X3J11. What was it? > _POSIX_SOURCE, specified as being supplied by the > APPLICATION, not the implementation, was specified as turning OFF > POSIX-permitted extensions, but what was really needed was a way to > turn ON ANSI C-prohibited extensions, Where do you read this? I see in section 2.8.2.1: If there are no feature test macros present in a program, only the set of symbols defined by the C Standard shall be present. For each feature test macro present, only the symbols specified by that feature test macro plus those of the C Standard shall be defined when a header is included. In other words, _POSIX_SOURCE (a feature test macro) does turn on definition of symbols not defined by the C Standard (ANSI C-prohibited extensions). Perhaps you are thinking of section 2.8.2.2. First of all, that section only applies to common usage C, and thus has no bearing on ANSI C environments. Second, it defines only the state when _POSIX_SOURCE is defined, not the state when it is not defined (which is outside the scope of any standard) and thus not whether _POSIX_SOURCE has an additive effect, a subtractive effect, or any effect at all. > and in any event the vendors don't want to tell their customers > to #define _POSIX_SOURCE in order for their existing code to compile. Vendors who want their customers' existing code to compile unchanged will provide backward-compatible compilers and environments to permit that. The P1003.1 working group did not believe that many existing programs would conform to the new standard with zero change. > The simplest solution would have been: > cc # backward-compatible sloppy UNIX mess version > acc # ANSI-conforming version > pcc # POSIX- and ANSI-conforming version > fcc # like "pcc" but with extra ANSI-prohibited stuff. If this is still under the assumption that 1003.1 preserved strict ANSI C conformance, I don't see why pcc would be needed at all; it could be synonymous with acc. If we accept that (and the analogous relations with other, future standards) as impossible, what happens when 1003.2 adds popen() to <stdio.h> and 1003.4 adds symbols to 1003.1 headers like <fcntl.h> and <sys/stat.h>? Do we add new commands like: p12cc # 1003.1 and 1003.2 conforming p2cc # 1003.2 conforming p14cc # 1003.1 and 1003.4 conforming p124cc # 1003.1, 1003.2, and 1003.4 conforming The "feature test macro" approach introduced in 1003.1 seems to handle this much more cleanly, with N names rather than up to 2**N names for N standards. > cc __STDC__ not defined > acc __STDC__==1 > pcc __STDC__==1 > fcc __STDC__ not defined I don't understand this at all (assuming pcc is needed at all - see above). From the ANSI C perspective, pcc and fcc should be identical; they are ANSI C with a polluted namespace. The fact that pcc has its pollution defined by a clear standard while fcc doesn't makes no difference here. Practically I think that ANSI C should explicitly permit the namespace to be used in any way explicitly or implicitly specified by the user, as long as there is a clearly documented way to get a completely clean namespace. Thus invoking pcc or fcc or "acc -DFOO" as defined here should leave __STDC__ == 1, as long as the effect on the namespace is clearly documented. As others have stated, the predefine is not at all useful in dealing with namespace pollution, beyond (perhaps): #if !__STDC__ #error #endif > >The best I see that could be done here is to make a strong > >recommendation that POSIX vendors define > >__ANSI_C_EXCEPT_FOR_POSIX_STUFF__ (or some other specified name) to > >match what __STDC__ would have been defined as had the "allow POSIX > >stuff" flag not been given to the compiler. > > Practically ANY de facto standard not involving __STDC__ would be fine > so far as I'm concerned. As it stands, we have no satisfactory > solution. I'm not sure what problem is being addressed here, but I think there are solutions to all the real problems except one. If an application is compiled with the straight ANSI compiler, it can test __STDC__ for whatever it is interested in. It can define _POSIX_SOURCE itself if it wants POSIX symbols. If it wants to know whether POSIX is supported, it can then test _POSIX_VERSION from <unistd.h> (although the include of <unistd.h> may fail on a non-POSIX system, I doubt this would be an issue to any application that cared about this question). The only unsolved problem is whether the compiler which (at least effectively) pre-defines _POSIX_SOURCE can define __STDC__. I repeat that from a practical perspective I think it should, as long as there's a way to get a truly clean namespace. __ANSI_C_EXCEPT_FOR_POSIX_STUFF__ falls into exactly the same trap as the different compiler names, when N standards enter the picture there are up to 2**N possibly meaningful symbols. We could add one symbol like __ANSI_C_EXCEPT_POSSIBLE_NAMESPACE_ADDITIONS_AS_REQUESTED_IN_INVOCATION__. My point is that such a symbol seems far more useful than the strict __STDC__, and it makes more sense to make that the meaning of __STDC__. 1003.1 could have addressed this by requiring one of two symbols like _POSIX_STANDARD_C or _POSIX_COMMON_C to be defined, but that really seems to be redundant with the purpose of __STDC__, and in the scope of a language standard rather than an OS standard. > It's really unfortunate that 1003.1 didn't straighten out more of the > name space problems historical UNIX has had. I think it's unfortunate that X3J11 didn't consider that the C library is (at least in some valid cases) a foundation upon which other environments build rather than a complete environment, and thus didn't allow for graceful additions to the namespace consistent with existing practice. If they had addressed the problem sufficently and explained the solution clearly, there wouldn't be all this debate about how 1003.1, Microsoft, AT&T, et. al. are dealing with the situation. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com
mike@arizona.edu (Mike Coffin) (01/20/89)
This is really getting messy. I originally advocated setting
__STDC__ = 0 to indicate "almost ANSI", or "so close to ANSI we doubt
if you'll notice." This was rejected essentially on the grounds that
if you set it to 0 it is easy to write code that accidentally thinks
that it is 1. (I.e., using #ifdef instead of #if.)
Now people are instead advocating setting it to 1 even if the compiler
is nonconforming, so long as the non-conformance is "minor" or
"harmless." Yuk! I think it is a BIG mistake to define
__STDC__ = 1 if the compiler is nonconforming. Please don't lie to
my code.
We started by arguing that "#ifdef __STDC__" should guarantee that the
compiler is conforming --- no ifs ands or buts. The point was made
that if it wasn't ANSI, no one knows WHAT it might be. Now we're
saying that even if you carefully write "#if __STDC__ = 1", you can't
expect to get ANSI compliance.
This sounds very bad.
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike
Tucson, AZ 85721 (602)621-2858gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/21/89)
In article <398@jhereg.Jhereg.MN.ORG> mark@jhereg.MN.ORG (Mark H. Colburn) writes: >By the same token, the user could specify -D__STDC__ on the command line >to the C compiler. That would not necessarily make the compiler being >used an ANSI C conforming compiler... In fact, this seems like a good way for users on nonconforming implementations that have a lot of so-called "ANSI C" features to avail himself of them. It's his responsibility for limiting his program's use of __STDC__ to access just features the nonconforming implementation actually provides. That's much better than the implementation unconditionally pretending to be something it's not.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/21/89)
In article <8792@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >Now people are instead advocating setting it to 1 even if the compiler >is nonconforming, so long as the non-conformance is "minor" or >"harmless." Only in cases where NO strictly-conforming application could tell the difference. That's the only circumstance for which I think __STDC__ has a genuine use in applications. The worst effect it could have on not strictly conforming applications is that they might not try to use compatible vendor extensions since they would be led to think that they didn't exist in this environment. That doesn't bother me one bit.
guy@auspex.UUCP (Guy Harris) (01/21/89)
>>if you stick a "#else" in there at that level, what goes between it >>and "#endif"? > >Whatever is already going on in the existing pre-ANSI C implementation. >The reason we needed a standard was that this was pretty much a random >approximation to what K&R seemed to be saying, plus various additional >inventions done wildly differently by different implementors. Yes, I know that's why a standard was needed. The problem is that there is no "the" existing pre-ANSI C implementation, so you have to have some particular target or targets in mind when you write the code that goes there. I presume you are thinking of situations where that is the case (or where you're willing to deal with new targets as you come across them, as in your later example of <varargs.h>)? >the bottom line is that a PARANOID programmer is advised to write > #ifdef __STDC__ > #if __STDC__ > 0 > #define MY_STDC_INDICATOR 1 > #endif > #endif >then use MY_STDC_INDICATOR instead of __STDC__, Or, as Peter da Silva pointed out, to write #ifndef __STDC__ #define __STDC__ 0 #endif then just use "#if __STDC__". >The main problem seems to be that vendors want to include their old >extra UNIX cruft in <stdio.h> without requiring their customers to >use a different form of compilation from the ANSI C mode. Even 1003.1 >wants to do this. By "extra UNIX cruft", do you mean POSIX stuff (e.g., "fdopen" and "fileno"), or stuff over and above that? >What I would have for the two names known to the programmer in each >of the four cases are: > cc __STDC__ not defined > acc __STDC__==1 > pcc __STDC__==1 In other words, even though including <stdio.h> when compiling in "POSIX+ANSI" mode would cause "fileno" and "fdopen" to be declared if functions, or defined if macros, __STDC__ should be defined anyway? (If it neither defines nor declares them, I don't see how "acc" differs from "pcc"....) I agree that this is OK, but I was under the impression that it would violate the letter of the standard. > fcc __STDC__ not defined > >I think AT&T has in mind the use of __STDC__==0 in the "fcc" case >instead of coming up with their own secret symbols, and merging >"cc" and "fcc" together into one case, and "acc" and "pcc" into a >second case. No, I think their intent is that: the moral equivalent of "cc" be "traditional C + whatever ANSI C things don't break traditional C + UNIX" - i.e., unsignedness-preserving conversions, Reiserisms, etc.; the moral equivalent of "acc" be STRICT ANSI C - no "fdopen" nor "fileno", for example; the moral equivalents of "pcc" and "fcc" perhaps be merged into one, leaving it up to the user to distinguish POSIX-only from S5R4. __STDC__ would (according to other postings reporting from the S5R4 Developer's Conferences - my memory of AT&T's requirements documents gives out at this point) be defined as 0 in the "moral equivalent of 'cc'" case; I don't know if it'd be defined as 0 or 1 in the "moral equivalents of 'pcc' and 'fcc' case", but I think the intent may be to define it as 0, so that "#if !__STDC__" would protect all extensions that chew up the ANSI C namespace. >It's really unfortunate that 1003.1 didn't straighten out more of the >name space problems historical UNIX has had. How would you suggest it have done that? (I don't think a solution of "rename 'fdopen' and 'fileno'" would have been accepted by consensus. *I'd* certainly have been ticked had they done that; had they done that, I would have insisted that they delete the "IX" from "POSIX", so that they don't pollute the namespace of UNIX-flavored systems....)
w-colinp@microsoft.UUCP (Colin Plumb) (01/21/89)
peter@ficc.uu.net (Peter da Silva) wrote: > If you really want to survive __STDC__==0, then here's a workable solution... > This will mean you will always have __STDC__ defined as 0 or 1. No, no, no... the argument (and I'm starting to see the opposition's points) is that *almost* ANSI-compliant compilers (i.e. ones that accept all the ANSI C syntax features, but may have polluted namespaces), should #define __STDC__ 0. K&R compilers should not define it at all. Basically, this tells you the compiler won't barf on prototypes or forward struct references or const or volatile or unary + or ... or # and ## or defined() or any such ANSIism. You still have to worry about finding the right headers and strrchr and all the library mess that currently exists. The compiler comes halfway. -- -Colin (uunet!microsof!w-colinp)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/21/89)
In article <320@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >The compiler comes halfway. But WHICH half??
mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) (01/22/89)
In article <320@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >Basically, this tells you the compiler won't barf on prototypes or >forward struct references or const or volatile or unary + or ... >or # and ## or defined() or any such ANSIism. You still have to worry >about finding the right headers and strrchr and all the library mess >that currently exists. The compiler comes halfway. The problem that others (such as Doug Gwyn) are looking at is does it really understand all of the things that you mentioned, such as function prototypes, #, ##, unary plus, etc.? What if it just understands function prototypes, const, volatile and forward structure references? I would bet there there are going to be vendors out there that decide that that is going to be good enough to define __STDC__. As a developer, I'm going to be very annoyed when my "maximally portable application" is compiled on their system and fails due to a syntax error when it encounters a unary plus. Basically, what I think (I won't speak for any others) is that the only system that is close enough to the standard to define __STDC__ is one that is fully conformant. When I was in high-school I had a science teacher who, when we asked how close to the correct answer we had to be, would respond: "How close do you have to be to kiss your girlfriend?" I think that it follows here too... -- Mark H. Colburn "They didn't understand a different kind of Minnetech Consulting, Inc. smack was needed, than the back of a hand, mark@jhereg.mn.org something else was always needed."
bill@twwells.uucp (T. William Wells) (01/22/89)
In article <9405@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
: "Rough ANSI compliance" is meaningless
: and useless to the portable application programmer. "Strict ANSI
: compliance", on the other hand, is a meaningful notion of considerable
: utility to the programmer. In order for it to HAVE this utility,
: though, we need the symbol __STDC__ reserved for making the distinction.
This is the key to the disagreement: you believe that "Rough ANSI
compliance" is "useless to the portable application programmer".
Others do not.
While it is certainly true that an "almost" ANSI compiler can differ
from the standard in any arbitrary way, I suggest that many such will
often differ in uninteresting ways, or in ways that are easily dealt
with.
If this is the case (and the current situation seems to indicate that
is how things will be), the "almost" ANSI compiler will be in much the
same kind of class as one for BSD or SYSV, that is to say, one which
has a core of common features but irritating differences from those
in the class, and significant differences from those outside the
class.
In other words, "almost" ANSI would leave us in exactly the same
situation we have now, but with one more common environment to deal
with.
For those who don't mind (or don't understand) the current situation,
adding one more class of environments isn't likely to cause any
perceived hardship. For those that do, doing so is like going back to
the stone ages.
On the other hand, those who want some way of discovering "almost"
ANSI compliance have a valid point. Strictly speaking, if I run cc
-D..., the compiler is no longer conforming; thus, the compiler ought
not define __STDC__. Of course, there is nothing *preventing* the
compiler writer from simply documenting that using certain compiler
switches makes the compiler non-conforming, and leaving it at that.
But if we do that latter, we defile the "purity" of __STDC__. But if
we don't, we can't have programs whose compilation depends both on
ANSI features and on compile time switches.
Here is a suggestion:
For "almost" ANSI compilers, I don't use __STDC__ to identify them;
instead, I have a set of defines in a universal include file (which
gets included before any of my include files) which I turn on for
various features available with the compiler. This include file might
look like:
#ifdef sun3 /* standard SunOS compiler */
#define HAS_VOID
#define BROKEN_VOID
#define HAS_UCHAR
#define HAS_ULONG
...
#define SYS_DEFINED
#endif
#ifdef MSC /* Microsoft compiler */
#define ANSI_PREP
#define ANSI_PROTO
#define ANSI_INCLUDE
#define HAS_VOID
#define HAS_UCHAR
#define HAS_ULONG
...
#define SYS_DEFINED
#endif
...etc.
/* This SYS_DEFINED is a kludge; it is needed for those !@#$%
compilers that define their own symbol and then go on to define
__STDC__. Note that this is the only place __STDC__ gets
referenced; if one wants an ANSI feature, one needs to have a
define for it that gets set here. */
#ifndef SYS_DEFINED
#ifdef __STDC__
#define ANSI_PREP
#define ANSI_PROTO
#define ANSI_INCLUDE
#define HAS_VOID
#define HAS_UCHAR
#define HAS_ULONG
...
#endif
#endif
#undef SYS_DEFINED
Now then, we come to the question: what should an implementation do
if some compile time switch renders the compiler nonconforming? One
solution is for the compiler to reverse the above: without the
switch, define __STDC__, with it, define a special symbol for the
compiler.
I think that is ugly; furthermore, it really doesn't deal with the
situation. Since I set the compiler switch, I ought to know what way
the switch changes the compiler's behavior; I should have arranged
that, when using the switch, the program compiles correctly. In other
words, what I want is a compiler which is ANSI, but which has just
those changes represented by the compiler switch. (And if I want the
compiler to not pretend to be ANSI, I can just -U__STDC__ or the
equivalent.)
I propose that __STDC__ == 0 be reserved (obviously only custom can
apply here) for use by compilers that are conforming when no compiler
switches are specified. Those compilers would set __STDC__ == 1 then.
When the user specifies any switch that makes the compiler non-
conforming, it sets __STDC__ to 0.
There are two advantages to the above. The first is that the
programmer gets a meaningful __STDC__, even when he has used a compile
time switch. This is particularly useful when one is writing
conforming (but not strictly conforming) programs which are to be
portable between different environments.
The second is more subtle: by defining a meaning for __STDC__ == 0,
we have a standard by which we can judge the use of __STDC__;
pressure to comply with this "standard" may help get rid of those
compilers that use __STDC__ == 0 to mean that the compiler is
"almost" ANSI.
In summary:
A compiler whose normal mode is not ANSI should not define
__STDC__.
A compiler whose normal mode is ANSI should define __STDC__
== 1.
A compiler whose normal mode is ANSI, but which is operating
in a different mode, specified by compile switches or other
means which require the user to turn them on, defines __STDC__
== 0.
---
Bill
{ uunet!proxftl | novavax } !twwells!billnagel@paris.ics.uci.edu (Mark Nagel) (01/22/89)
In article <406@jhereg.Jhereg.MN.ORG>, mark@jhereg (Mark H. Colburn) writes: | |The problem that others (such as Doug Gwyn) are looking at is does it |really understand all of the things that you mentioned, such as function |prototypes, #, ##, unary plus, etc.? What if it just understands function |prototypes, const, volatile and forward structure references? I would bet |there there are going to be vendors out there that decide that that is |going to be good enough to define __STDC__. As a developer, I'm going to |be very annoyed when my "maximally portable application" is compiled on |their system and fails due to a syntax error when it encounters a unary |plus. This is what I don't understand -- why should *you* be annoyed because your conforming program fails to compile on a fake ANSI implementation? For years now we've heard "if it does/doesn't do so and so, then it ain't a C compiler." Along with this was the implicit message that the compiler should be replaced with one that *is* conforming. Why can't it be the same now? I realize that for some people, there is only one choice. But in general, it should be possible to simply avoid purchasing/using a compiler that is broken in favor of one that is capable of compiling conforming programs. Why should users adjust for the compiler writers' benefit? |Basically, what I think (I won't speak for any others) is that the only |system that is close enough to the standard to define __STDC__ is one that |is fully conformant. Exactly. So don't even worry about what happens when __STDC__ is defined when it shouldn't be. That's the compiler customer's problem, not the program writer's. I know, I know, you're all saying, "Join us here in the real world, Mark." But this is exactly what the standard is supposed to do -- give *everyone* the same base of known language features and capabilities. I have no sympathy for someone who continues to use a faulty compiler when other choices exist (e.g. Gnu, when it's done). Mark Nagel @ UC Irvine, Dept of Info and Comp Sci ARPA: nagel@ics.uci.edu | The world is coming to an end. UUCP: {sdcsvax,ucbvax}!ucivax!nagel | Please log off.
henry@utzoo.uucp (Henry Spencer) (01/22/89)
In article <9445@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >__STDC__==0 tells me NOTHING... I would say, rather, than it tells you nothing portably. It may still be useful in a specific environment. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
geoff@warwick.UUCP (Geoff Rimmer) (01/23/89)
How about putting the following lines in /usr/include/local/__STDC__fix.h #ifdef __STDC__ #if __STDC__==0 #undef __STDC__ #endif #endif and then at the top of every source file, put #include <local/__STDC__fix.h> I know it's a bit messy, but it would work wouldn't it? Geoff ------------------------------------------------------------ Geoff Rimmer, Computer Science, Warwick University, England. geoff@uk.ac.warwick.emerald "I assure you Brad's presence here comes as a complete surprise" DIDN'T YOU READ THE SCRIPT? - Rocky Horror Picture Show, 1975 ------------------------------------------------------------
dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/24/89)
In article <344@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >...by defining a meaning for __STDC__ == 0, >we have a standard by which we can judge the use of __STDC__... An excellent idea. Self-respecting compiler writers would not casually define __STDC__ == 0 if the ANSI standard gave a specific meaning to it. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/25/89)
In article <5414@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >An excellent idea. Self-respecting compiler writers would not casually >define __STDC__ == 0 if the ANSI standard gave a specific meaning to >it. What meaning COULD the Standard give for it? I suppose __STDC__==1 could be reserved for conforming HOSTED implementations and __STDC__==0 reserved for conforming FREESTANDING implementations, but that's about it. (Also, several implementors would complain about that specific formulation.) The legalistic problem is that the Standard cannot validly specify WHAT a nonconforming implementation must do. It already specifies __STDC__ for conforming implementations.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/25/89)
In article <944@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes:
-#ifdef __STDC__
-#if __STDC__==0
-#undef __STDC__
-#endif
-#endif
I have no guarantee that the implementation will allow my program
to #undef __STDC__. I suspect that some won't.friedl@vsi.COM (Stephen J. Friedl) (01/25/89)
In article <944@ubu.warwick.UUCP>, geoff@warwick.UUCP (Geoff Rimmer) writes: > How about putting the following lines in /usr/include/local/__STDC__fix.h > > #ifdef __STDC__ > #if __STDC__==0 > #undef __STDC__ > #endif > #endif You can't always #undef __STDC__, even for nonconformant compilers. Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for you only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl Nancy Reagan on these *stupid* .signatures: "Enough already, OK?"
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/28/89)
In article <2525@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes: > 2) Should it #define __STDC__ to be 1 by default? > First off, can it? Of course it CAN; a nonconforming implementation can do anything it wants. The question is, if it did, would that cause problems for applications? The answer to that is definitely YES, it would. > Because it declares the extra functions, does that prevent it > from being a "fully conforming" ANSI C compiler? Yes, it does. If the visibility of the extra functions in the standard headers is controlled by #ifdef _POSIX_SOURCE, on the other hand, then that is not non-conforming, provided that _POSIX_SOURCE is not predefined by the implementation. > Perhaps it SHOULD #define __STDC__ as 1 for both modes. No, it shouldn't -- it definitely CAN matter to a strictly-conforming C application, and if __STDC__ were 1 in such a non-conforming environment, the application would have no way to determine that it is going to have a problem. I can accept __STDC__==0 for this, if we get near-universal agreement on it, but not __STDC__==1 in ANY non-conforming environment, no matter how "small" you consider the deviation to be. For __STDC__==1, I consider that it suffices for practical purposes to consider an implementation conforming if no strictly-conforming C program can detect the difference. Thus it wouldn't bother me for __STDC__ to be set to 1 in an environment that provides upward-compatible extensions to ANSI C. Extra identifiers usurped from the application's name space do not qualify as upward-compatible extensions. > 3) Is the SVr4 C compiler useful with this scheme? > My feeling is yes. I can use "#ifdef __STDC__" to fully differentiate > within my code between the old K&R C and new ANSI C syntaxes. But syntax is not the only difference between those two C environments. >By the way, I also reject the opinion that using -D when invoking an ANSI C >compiler: > ansicc -Dxyz >should suddenly cause __STDC__ to be undefined. (Sorry Doug, I think you're >wrong here.) I've since acknowledged that so long as the predefinition is being done explicitly by the compiler user, not automatically by the compiler, it would be most usefully considered as shorthand for editing all the sources to temporarily "#define xyz 1". Therefore that would not be a "predefined" identifier in the ANSI C sense and would not require that __STDC__ be changed from its normal value (1, 0, not defined, whatever). On the other hand, if the compiler automatically predefines macros in the application's reserved name space, or if it automatically predefines macros in its own name space that cause other identifiers in the application's name space to be usurped (e.g. _POSIX_SOURCE), then I definitely want __STDC__ to NOT be set to 1.
turner@sdti.SDTI.COM (Prescott K. Turner) (02/09/89)
The discussion of __STDC__ has been strongly directed towards the issues of
what implementations should do. Several articles have mentioned that the
standard could not indicate what a non-conforming implementation should do
with __STDC__.
It's too late now, but the standard could have said more about how
standard-conforming programs use __STDC__. The effects of this might have
been interesting and useful.
In fact, its failure to say more will probably doom the plan to define
__STDC__ to 2 in future standards. Consider the following strictly
conforming program:
#if __STDC__ == 1
#include <stdio.h>
int main() {
printf ("Hello, world.\n");
return 0;
}
#else
PROGRAM HELLO
PRINT *, "Hello, world."
END
#endif
Many standard C programs will use __STDC__ with the same #if directive as
above. If the next standard defines __STDC__ to 2, it will not provide
upward compatibility for these programs. Many programs would do the "wrong"
thing.
If this had been thought out ahead of time, the present standard might have
required a conforming program to have the same output when run
with a compiler which is otherwise standard-conforming but which has
__STDC__ defined to 2,3,4,5 or ... .
Another reason for the standard to constrain the way a program uses __STDC__
would be for the indirect influence on non-conforming C compilers. This
could conceivably steer C compilers towards a "correct" way of defining
__STDC__, since most non-conforming compilers would be required by the
user community to support programs which use __STDC__ in whatever way
becomes widespread. But I don't really have any wording to suggest as
a hypothetical addition to the standard along these lines.
--
Prescott K. Turner, Jr.
Software Development Technologies, Inc.
375 Dutton Rd., Sudbury, MA 01776 USA (508) 443-5779
UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.comkarl@haddock.ima.isc.com (Karl Heuer) (02/15/89)
In article <355@sdti.SDTI.COM> turner@sdti.SDTI.COM (Prescott K. Turner, Jr.) writes: >In fact, its failure to say more will probably doom the plan to define >__STDC__ to 2 in future standards. [Because many programs will write >#if __STDC__ == 1 and will break if it ever becomes 2.] The unofficial portions of the Standard do mention the intent to make __STDC__ have the value 2 in the future. Therefore, I hold the opinion that anyone who ignores this deserves what they get. Likewise for anybody who knowingly depends on a deprecated feature. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
ado@elsie.UUCP (Arthur David Olson) (02/16/89)
> In fact, its failure to say more will probably doom the plan to define > __STDC__ to 2 in future standards. [Because many programs will write > #if __STDC__ == 1 and will break if it ever becomes 2.] #if __STDC__ >= 1 -- Arthur David Olson ado@ncifcrf.gov ADO is a trademark of Ampex. #endif /* __STDC__ >= 1 */
nevin1@ihlpb.ATT.COM (Liber) (02/23/89)
In article <9075@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: |> In fact, its failure to say more will probably doom the plan to define |> __STDC__ to 2 in future standards. [Because many programs will write |> #if __STDC__ == 1 and will break if it ever becomes 2.] |#if __STDC__ >= 1 You don't really want to do this, since the future standard may not be 100% upward compatable with ANSI C 89. -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/23/89)
In article <9710@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes: >In article <9075@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >|#if __STDC__ >= 1 >You don't really want to do this, since the future standard may not be >100% upward compatable with ANSI C 89. It's much more likely that "#if __STDC__ > 0" will be what you want under a future revision of the Standard than that "#if __STDC__ == 1" will be.