On 8/26/06, Michael Veksler <[EMAIL PROTECTED]> wrote:
Jack Howarth wrote: > Would any of the gcc developers care to drop by the python-dev > mailing list and give the author of python an answer? > > http://mail.python.org/pipermail/python-dev/2006-August/068482.html > > *Guido van Rossum wrote: * > I'm not sure I follow why this isn't considered a regression in GCC. > Clearly, on all current hardware, x == -x is also true for the most > negative int (0x80000000 on a 32-bit box). Why is GCC attempting to > break our code (and then blaming us for it!) by using the C standard's > weaselwords that signed integer overflow is undefined, despite that it > has had a traditional meaning on 2's complement hardware for many > decades? If GCC starts to enforce everything that the C standard says > is undefined then very few programs will still work... > First, you can always use -fwarpv and retail old behavior. Any code that breaks or suspects breakage by the new behavior may use this flag.Second, consider the following example: Once upon a time int *p; /* No init!!! */ if (*p && 0) *p=0; would not crash (DOS days). One could say "Why should Microsoft or Borland crash our code? Clearly, the value of "p" should never be read or written". This example broke when we had memory protection. Memory protection is a good thing, right?
I find that a rather condescending example and not at all of the same nature.
Similarly, the new gcc behavior allows for better optimization. Also, we are told that some boxes, have different codes for signed and unsigned operations, where signed overflows either trap or saturate (IIRC on x86, MMX saturates on overflow)
Then it would behoove GCC to warn users about code that might depend on that h/w feature when compiling for that box, rather than silently breaking everyone's code everywhere.
Once I had a similar claim to yours (against this overflow behavior): http://gcc.gnu.org/ml/gcc/2005-06/msg01238.html But after extensive searches, I could not find code that breaks due to this new behavior of overflow. Such code is apparently rare.
And now you've found an example but you continue your claim? Defending a position with condescending examples and false claims does not improve the position. I know I cannot win an argument with the GCC developers but I can't help wondering if they've gone bonkers. They may get Python 2.5 fixed, but what about 2.4? 2.3? This code has been there for a long time. It would be better if one had to explicitly request this behavior, rather than explicitly disable it. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
