bright@Data-IO.COM (Walter Bright) (05/02/89)
In article <17.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes:
<Zortech's C++ V1.07c. I presume it's the most recent release since I
<was recently shipped it for review. It says __STDC__ == 1 and won't
<hand ??= as #. I'm sure it is missing numerous other things too -
You're right. When you compile with the -A switch, the compiler sets
__STDC__ to 1. When you don't, it won't. Trigraphs weren't implemented
in that version of the compiler because the ANSI C document was still
undergoing revisions, and due to the number of people who obviously
disliked trigraphs (including me!) I suspected that they would go the
way of noalias. I had implemented several ANSI features at one time, only
to see them get changed or dumped in subsequent revisions of the standard.
It's still premature to rate compilers on ANSI compliance since the standard
has not been signed off yet.
It's also interesting to note that many people seem to believe that ANSI
conformance == no bugs. This is completely unrealistic. A full ANSI compiler
is very complex, and therefore will have bugs in it. In the absence of an
officially endorsed ANSI certification process, the best that can be hoped
for is ongoing effort by compiler vendors to eliminate any problems.
That shouldn't be any problem, as pressure from customers for absolute
conformance is very strong.scs@adam.pika.mit.edu (Steve Summit) (07/02/89)
I don't want to open the whole __STDC__ can of worms again, but I
have two questions:
1. Is there anything to the argument that nobody should be
setting __STDC__ to 1 yet, since the standard isn't approved,
and that everyone should, at this point, be setting it to 0 to
indicate as much conformance to the draft as they can manage
(and not "we have prototypes and the useful stuff but not hair
like trigraphs" or similar half-compliance schemes which have
been so thoroughly denounced)? (This may be a frivolous
question; don't flame if you find it so.)
2. Why is it forbidden to re#define __STDC__? In a previous
article, I discussed needless restrictions, and this seems to
me to be one. Why shouldn't a program re#define __STDC__, if
it really wants to and is prepared to accept the consequences?
Why would a program want to, you ask? In an open system, the
burden of proof is on the implementor to show why a
restriction is necessary, not on the user to provide a useful
counterexample.
Even so, I can provide a realistic example of why mucking with
__STDC__ would be useful: suppose I am interested in keeping my
code compatible with earlier, non-ANSI compilers (a far from
hypothetical suggestion). If my primary development machine uses
an ANSI compiler, I might from time to time want to check if the
changes and additions I have been making are (at least
syntactically) still usable on the non-ANSI machine, without
necessarily taking all of the code over to the old machine and
compiling it. It seems natural to say
cc -U__STDC__
yet this is forbidden. It is claimed to make the compiler
writer's life easier, having perhaps something to do with vendor-
supplied header files, but even if the header files have #ifdefs
on __STDC__ in them (perhaps to make them usable with a non-ANSI-
compliant invocation mode) the old give-him-enough-rope-to-hang-
himself philosophy says that I ought to just get obscure errors
(if in fact there are obscure conflicts). (No :-), I'm serious.)
Instead, the compiler writer, as I understand it, is obliged to
have code like
cppdefine(name, value)
char *name, *value;
if(strcmp(name, "__STDC__") == 0 || strcmp(name, "__LINE__") == 0 ...)
{
error("illegal re#definition of %s", name);
return ERROR;
}
in the preprocessor. I can maybe understand the prohibition on
re#defining __LINE__, since it may well be implemented strangely
(its value changes practically every time you expand it) and
re#defining it therefore ineffectual, but prohibiting changing
__STDC__ just keeps me from doing what I want to do without
affecting the compiler at all (other than adding an extra test).
I don't believe that it is the compiler (or preprocessor)
writer's job to protect the header file author from me; if I muck
with __STDC__ and it breaks a standard header file, that's my
problem, not the compiler's.
Steve Summit
scs@adam.pika.mit.edurfg@pink.ACA.MCC.COM (Ron Guilmette) (07/03/89)
In article <12378@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >I don't want to open the whole __STDC__ can of worms again, but I >have two questions: > >1. Is there anything to the argument that nobody should be > setting __STDC__ to 1 yet, since the standard isn't approved, > and that everyone should, at this point, be setting it to 0 to > indicate as much conformance to the draft as they can manage... Are preprocessors supposed to implement floating-point comparisons? Maye be should have: #define __STDC__ 0.8 ... #if (__STDC__ >= 0.9) ... #endif Just kidding folks. :-) -- // Ron Guilmette - MCC - Experimental Systems Kit Project // 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740 // ARPA: rfg@mcc.com // UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
bill@twwells.com (T. William Wells) (07/05/89)
In article <12378@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
: Even so, I can provide a realistic example of why mucking with
: __STDC__ would be useful: suppose I am interested in keeping my
: code compatible with earlier, non-ANSI compilers (a far from
: hypothetical suggestion). If my primary development machine uses
: an ANSI compiler, I might from time to time want to check if the
: changes and additions I have been making are (at least
: syntactically) still usable on the non-ANSI machine, without
: necessarily taking all of the code over to the old machine and
: compiling it. It seems natural to say
:
: cc -U__STDC__
:
: yet this is forbidden.
In fact, for exactly the reasons you mention, I modified gcc's
preprocessor to permit me to do just that.
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.comdfp@cbnewsl.ATT.COM (david.f.prosser) (07/06/89)
In article <12378@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >I don't want to open the whole __STDC__ can of worms again, but I >have two questions: > >2. Why is it forbidden to re#define __STDC__? In a previous > article, I discussed needless restrictions, and this seems to > me to be one. Why shouldn't a program re#define __STDC__, if > it really wants to and is prepared to accept the consequences? The pANS only requires that a portable (i.e. strictly conforming) program must not have a #define or #undef for one of the predefined identifiers or defined. The reason why __STDC__ is included in the list of these identifiers is mostly one of generality: it makes no sense (as you note) to change the value of "generated" macros such as __LINE__, and __STDC__ is the only possible candidate for redefining for which a case can be made. If the pANS were to allow the redefinition of __STDC__, then either some behavior "loophole" would be required (this is actually the current status), or some well-defined result would need to be defined. The latter is most likely not to be worth the trouble. The pANS does not require a diagnostic message if an attempt is made to violate this restriction. It seems reasonable, to me, for the preprocessing phase to allow the redefinition of __STDC__, but this is a "quality of implementation" issue. Nevertheless, a portable program could use its own macro (MY__STDC__) that is used to get the effect of __STDC__: #ifndef MY__STDC__ # ifdef __STDC__ # define MY__STDC__ __STDC__ # endif #else # undef MY__STDC__ #endif Then, with -DMY__STDC__, you get the "old fashioned" part of the code, and with no option, you get MY__STDC__ as tracking the value of __STDC__. For maximal portability, it can be argued that a prudent programmer will isolate all uses of __STDC__ into a single spot so that the variations in "conformance" can be managed. Dave Prosser ...not an official X3J11 answer...
diamond@diamond.csl.sony.junet (Norman Diamond) (07/06/89)
In article <12378@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
- if(strcmp(name, "__STDC__") == 0 || strcmp(name, "__LINE__") == 0 ...)
- {
- error("illegal re#definition of %s", name);
- return ERROR;
- }
-
-in the preprocessor.
Maybe just if (strncmp(name, "__", 2)) ...
After all, the name subspace beginning with "__" belongs to the
implementation.
--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
The above opinions are claimed by your machine's init process (pid 1), after
being disowned and orphaned. However, if you see this at Waterloo, Stanford,
or Anterior, then their administrators must have approved of these opinions.