gcc trunk vs python

[Guido van Rossum]

On 8/26/06, Michael Veksler <mveksler@techunix.technion.ac.il> 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/)