From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Morgan-Linial To: craig@jcb-sc.com Cc: gcc@gcc.gnu.org Subject: Re: type based aliasing again - meaning of "undefined" Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: References: <19990915213450.16526.qmail@deer> X-SW-Source: 1999-09n/msg00650.html Message-ID: <19990930180200.Y9cCC4VQMTs4WK0x1xUycXL07LxVHcxn9Wny73sAWN8@z> On 15 Sep 1999 craig@jcb-sc.com wrote: > "imposes no requirement" presumably applies to the *implementation*, > i.e. the compiler, libraries, underlying machine, etc. Right. > Therefore, the apparent consistent behavior which you cite is, > according to the standard, completely irrelevant to the behavior > of an implementation, since the programs that violate the standard > by invoking undefined behavior aren't so much "erroneous" as they > *specifically* grant the implementation the freedom to do whatever > the heck it wants -- including doing the same thing the first 10 > million times that undefined behavior is invoked, then something > completely different (like "start World War 3") the next time. Sounds right (but why would anyone write a compiler that does that?). I think it's interesting that the example the standard gives for undefined behavior is integer overflow - imagine the uproar that would happen if you changed *that*. I guess it's just not obvious to me that the results of violating the type alias rules should be more like, say, dereferencing a null pointer (which I expect to cause problems) than like casting a pointer to an integer (which I usually expect to be consistent, if undocumented). Ross