Does ANSI insist this is legal?

[Roberto Shironoshita]

In article <25EC428B.18849 at paris.ics.uci.edu> rfg at ics.uci.edu (Ronald Guilmette) writes:
> In article <1990Feb28.180914.27504 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
> >In article <25EB8750.5286 at paris.ics.uci.edu> rfg at 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 at 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.