------- Comment #11 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-17 17:52 ------- (In reply to comment #10) > Please stop reopening. 6.3.1.3 is about casts between integer types. > Signed integer overflow is even mentioned as an example of undefined behavior > in 3.4.3.
Well, look, maybe you didn't notice what is this about so I should spell it out for you in a more explicit way so that you can understand it more clearly: 1. The test-case which is an issue here is triggering undefined behavior. I completely agree that it indeed does trigger it. I have no problem admitting it. 2. On the grounds that it is undefined behavior, you are claiming that the things which GCC currently does in case the undefined behavior gets triggered are OK - the validity of which follows from the fact that since the compiler's handling of an undefined state in a program is allowed to be arbitrary. Well, guess what, I completely agree with this and I have no problem accepting the validity of this reasoning. 3. Since the compiler's handling of an undefined state in a program is allowed to be arbitrary, the sequence A of actions GCC is currently doing while compiling the test-case is not the only valid one. There also exist other perfectly valid sequences of actions GCC *could* be doing while compiling the test-case. Even if those other sequences mean that the generated code has a completely different semantics (when the program reaches the undefined state) than the code generated if using A. (And yes, this even includes mixing in the not-directly related section 6.3.1.3 into the sequence of actions. Even that is perfectly valid, since anything is valid.) 4. You are saying that you are not going to change how the compiler deals with the test-case. On the other hand, I am saying that the compiler should handle the test-case in a different way. You cannot dismiss my suggestion, because it is a valid proposal - and I cannot dismiss your will to maintain the status quo, because it is a valid approach. 5. Who is going to win here? Obviously, the one who has more power and control. In this case it is you and the other GCC folks, because you have more control over how GCC gets developed, and because I am not willing to spend the time I have on persuading you that GCC should be patched. ... so, now I am going to reopen this bug to piss you all off just because I *subjectively* think that my proposal is better than the status quo. And you have absolutely no way of persuading me that I am doing something wrong or something against the C99 standard. So, there you have it: the beauty of letting the notion of undefined behavior slip into the formalization of a programming language. -- 0xe2 dot 0x9a dot 0x9b at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43089