Path: utzoo!attcan!uunet!mailrus!uflorida!novavax!hcx1!roberto From: roberto@ssd.csd.harris.com (Roberto Shironoshita) Newsgroups: comp.std.c Subject: Re: Does ANSI insist this is legal? Message-ID: Date: 4 Mar 90 20:44:29 GMT References: <25EB8750.5286@paris.ics.uci.edu> <1990Feb28.180914.27504@utzoo.uucp> <25EC428B.18849@paris.ics.uci.edu> Sender: news@hcx1.SSD.CSD.HARRIS.COM Reply-To: shirono@ssd.csd.harris.com Lines: 78 In-reply-to: rfg@ics.uci.edu's message of 28 Feb 90 21:28:43 GMT In article <25EC428B.18849@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: > In article <1990Feb28.180914.27504@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >In article <25EB8750.5286@paris.ics.uci.edu> rfg@paris.ics.uci.edu (Ronald Guilmette) writes: > >>Must a strictly conforming ANSI C implementation be able to generate an > >>executable program from the following? > >> > >> int main (); > >> short s = (short) &main; > >> char c = (char) &main; > >> int main () { return 0; } > > > >Holy Scriptures, Oct 88 draft, verse 3.3.4: > > > > A pointer may be converted to an integral type. The size of > > integer required and the result are implementation-defined. > > If the space provided is not long enough, the behavior is > > undefined. > > > >Your program falls under the jurisdiction of that last sentence, since > >it is vanishingly unlikely that a pointer will fit in a char and not too > >likely nowadays that it will fit in a short. So the compiler can remove > >all your files, send rude mail to your boss, and dump core if it wants. > > Well, this raises yet another question. > > I agree that any attempt to use a space which is not long enough (to hold > the pointer value initializer) can (allowably, under the standard) cause you > to lose all your files, can cause your boss to receive rude mail, and can > cause a core dump, but the $64,000 question is "When may these catastrophies > occur? At run-time or at compile-time? Either? Both?" Holy Scriptures, Dec. 88 draft, Chapter 1, verse 6: * Undefined behavior -- behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). So the answer is "BOTH". I'd like the $64,000 in small bills please ;-). > If the standard is trying to say that "the *run-time* behavior is undefined" > then that is one thing. If it is trying to say that the compiler may (or > can) flag an error at compile time, that is an entirely different thing. It seems to me that the standard says there is nothing it can (or cares to) say about the situation, and leaves it up to the implementors' good judgement to do some sensible thing (I'm not sure if Henry's example of undefined behavior qualifies as sensible ;-). From the definition of "undefined behavior" (now, that's a bit of standardese contradiction in terms;-), it may be concluded that, as far as the standard is concerned, both the compiler and the resultant executables form part of an implementation, and the behavior of the implementation includes both the compile-time and run-time behaviors. > Right now, GCC accepts the above program without complaint (but I'm sure > that is the values of `s' or `c' were used, that run-time strangeness > would ensue). The question is whether or not a standard conforming compiler > is *allowed* to "reject" the above code at compile time. As the quote says, the implementation is allowed to do pretty much anything it pleases, which includes termination of translation with issuance of diagnostic. -- || Internet: shirono@ssd.csd.harris.com Roberto Shironoshita || Harris Corporation || ...!novavax-\ Computer Systems Division || UUCP: -!hcx1!shirono || ...!uunet---/ DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.