🚀 go-pugleaf

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?"

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.

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.


// Ron Guilmette (rfg@ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.