ado@elsie.UUCP (Arthur David Olson) (02/18/88)
Having grown desperate, I'm stooping to offering a $1 check to the first person
who can convince me that the January 11, 1988 draft C standard prohibits the
implementer of a conforming hosted implementation from deciding that "main" is a
reserved external identifier. All decisions of the judge (me) are final.
Here's the background. The January 11 draft says, among other things:
* "A strictly conforming program shall use only those features of the
language and library speciried in this Standard. It shall not
produce output dependent on any unspecified, undefined, or
implementation-defined behavior. . ." (Page 4, Section 1.7)
* "A conforming hosted implementation shall accept any strictly
conforming program." (Page 4, Section 1.7)
* "All external identifiers declared in any of the headers are
resserved, whether or not the associated header is included. All
external identifiers that begin with an underscore are reserved.
All other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved. If the
program defines an external identifier with the same name as a
reserved external identifier, even in a semantically equivalent form,
the behavior is undefined." (Page 97, Section 4.1.2)
Now suppose an implementer decides that "main" is a reserved external
identifier. Nothing in the last section above seems (to me) to prohibit
the implementer from doing so. Nothing above seems (to me) to obligate the
implementer to declare "main" in a header; nor does the implementer have
to list the reserved external identifiers for me in an implementation document
(at least I can't find such a requirement in section A.6.3).
So when I try to use the program
#include "stdio.h"
main() { printf("Hello, world!\n"); return 0; }
I might very well get the output:
Goodbye cruel world!
because I've used a reserved external identifier, which means that my program
isn't strictly conforming, which means that the implementation can do anything
it wants with the program (a license granted by the "undefined behavior"
phrase in the first quote above).
I hope it's clear that I'm not losing sleep over some implementer actually
deciding that main is a reserved external identifier; I am, though, worried
about how I'm supposed to find out just what identifiers an implementer might
have reserved--because if I use one of them, anything at all might happen to
my programs.
I've include a
Followup-To: poster
to try to get responses routed my way; I'll post the first response that
convinces me.
--
I am solely responsible for this posting.
--
ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarksado@elsie.UUCP (Arthur David Olson) (02/26/88)
While the check has yet to be claimed, one correspondent has made me realize
that the Catch-22 applying to an "external reserved identifier" also applies
to a "keyword," as witness the following dialogue involving yours truly ("ME")
and an implementer ("IMP"):
ME: My program
main() { return 0; }
doesn't return zero.
IMP: Yeah. . .you misused a keyword.
ME: Huh?
IMP: Main. One of our extensions makes it a keyword.
You're not allowed to use it at all.
ME: What? You can't make that extension! It alters the
behavior of my strictly conforming program!
IMP: Your program isn't strictly conforming. You use a
(extended) keyword, which Section 3.1.1 says you shall
not do. The "shall not" is not in a "Constraint" section.
Section 1.6 says "If a 'shall' or 'shall not' requirement
that appears outside of a constraint is violated, the
behavior is undefined.' And since your program produced
"output dependent on. . .undefined. . .behavior," it isn't
strictly conforming, per Section 1.7.
Providentially, this Catch-22 is even easier to deal with than the
"external reserved identifier" one (with the addition of one word only),
changing the sentence in Section 3.1.1 that begins
The following tokens (entirely in lower-case) are reserved
(in translation phases 7 and 8) for use as keywords. . .
to begin
Only the following tokens (entirely in lower-case) are reserved
(in translation phases 7 and 8) for use as keywords. . .
(You have to add a whole sentence to fix the external reserved identifier
problem.)
--
ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarksgwyn@brl-smoke.ARPA (Doug Gwyn ) (02/26/88)
In article <8020@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: > IMP: Main. One of our extensions makes it a keyword. > You're not allowed to use it at all. This is silly. The proposed standard makes clear what the function of main() is; a strictly conforming program shall use only those features of the language and library specified in the Standard; a conforming hosted implementation shall accept any strictly conforming program; a conforming implementations may have extensions provided they do not alter the behavior of a strictly conforming program. I don't see how anyone could misinterpret the intent of all this, unless perhaps they were focusing on just one tiny portion of the Standard and ignoring the fact that it is the entire Standard that must be conformed to, not just an isolated portion of it.
ado@elsie.UUCP (Arthur David Olson) (02/28/88)
> > IMP: Main. One of our extensions makes it a keyword. > > You're not allowed to use it at all. > This is silly. The proposed standard makes clear what the function of > main() is. . . Oh well, so much for my efforts to keep my example program short. Let's try this slightly longer one: int xyzzy; main() { return 0; } Now last time I looked, xyzzy wasn't mentioned anywhere in the Standard, so the point made above about "main" doesn't apply. So let's head back to Pine Ridge and see what Lum ("IMP") and Abner ("ME") are up to. Listen: ME: By doggies, my program int xyzzy; main() { return 0; } doesn't return zero. IMP: By grannies, you're right. . .you misused a keyword. ME: Huh? IMP: Xyzzy. One of our extensions makes it a keyword. You're not allowed to use it at all. ME: What? You can't make that extension! It alters the behavior of my strictly conforming program! IMP: Your program isn't strictly conforming. You use a (extended) keyword, which Section 3.1.1 says you shall not do. The "shall not" is not in a "Constraint" section. Section 1.6 says "If a 'shall' or 'shall not' requirement that appears outside of a constraint is violated, the behavior is undefined.' And since your program produced "output dependent on. . .undefined. . .behavior," it isn't strictly conforming, per Section 1.7. -- ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarks
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/28/88)
In article <8022@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: > IMP: Xyzzy. One of our extensions makes it a keyword. > You're not allowed to use it at all. I still don't think that a conforming implementation is anywhere given license to introduce additional keywords. However, I agree that in addition to specifically mentioning constraints on identifier name space infringement as is currently done in the draft proposed standard, it would be useful to explicitly state such a constraint on keywords. This would guarantee that "pascal" (APW C keyword) and other such unexpected keywords would not conflict with what the application programmer was using for his own purposes. (It makes me uneasy to think that an ANSI C implementation would do this, so I can support a clearly stated injunction against it in the standard.) Note that we would presumably still want to allow conforming implementations to define new keywords as extensions, but their names should be constrained to start with an underscore, at the very least. This is in fact probably necessary in order to efficiently implement some library functions and macros on some systems. (It permits compiler "intrinsics", to use the Fortran terminology.)
karl@haddock.ISC.COM (Karl Heuer) (03/02/88)
In article <7365@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >[Nonstandard keywords] should be constrained to start with an underscore, at >the very least. I believe that to avoid colliding with the user's local variables, keywords (like machine-specific #defines) must begin with a double underscore or an underscore followed by an uppercase letter. I thought one of the more recent Drafts covered this issue. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/02/88)
In article <2801@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: >I believe that to avoid colliding with the user's local variables, keywords >(like machine-specific #defines) must begin with a double underscore or an >underscore followed by an uppercase letter. I thought one of the more recent >Drafts covered this issue. ADO and I don't seem to be able to find the part of the draft that so constrains keywords (as opposed to macro names and external identifiers). I'd appreciate a reference to the proper section number, or something.
ado@elsie.UUCP (Arthur David Olson) (03/02/88)
> > [Nonstandard keywords] should be constrained to start with an underscore, at > > the very least. > > I believe that to avoid colliding with the user's local variables, keywords > (like machine-specific #defines) must begin with a double underscore or an > underscore followed by an uppercase letter. I thought one of the more recent > Drafts covered this issue. Nope. Recent drafts say that application programmers aren't allowed to use __* and _[A-Z]* identifiers, which are reserved to implementers; recent drafts do not say that implementers may reserve *only* those identifiers. -- ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarks
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/03/88)
In article <8025@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >Nope. Recent drafts say that application programmers aren't allowed to use >__* and _[A-Z]* identifiers, which are reserved to implementers; recent drafts >do not say that implementers may reserve *only* those identifiers. The draft does not specify "programmers" or "implementers", just what identifiers are reserved, period. (4.1.2) Conforming implementations are prohibited from usurping other identifiers via any of the standard headers, and conforming programs cannot defined one of the reserved identifiers. A possible deduction that could be drawn from the rules is that for the most part, _-names are available for the implementation. I think the only real issue is that a keyword is not an identifier, so there is a possible loophole that should be closed. I'm pretty sure there wasn't any intention of allowing conforming implementations to define additional non-_ keywords. At least, that's my interpretation of the proposed standard..
henry@utzoo.uucp (Henry Spencer) (03/04/88)
> ... recent drafts > do not say that implementers may reserve *only* those identifiers. If you read section 1.7 very carefully and thoughtfully, you may change your mind. Assume your compiler reserves "xyz". Is a program which is otherwise "strictly conforming" rendered not so by using "xyz" for its own purposes? No. Is your compiler a "conforming implementation" if it refuses to compile that program as a result? No. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry