[Python-Dev] gcc 4.2 exposes signed integer overflows

[David Hopwood]

Jack Howarth wrote:
>     I believe some of the others here might be interested in
> some other postings on the gcc mailing list regarding this issue
> (which weren't cross-posted here)...
> 
> http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html
> http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html
> 
> It makes clear that the impact of this change in gcc was considered
> and the reasoning on their decision to follow the standard so closely.
> 
> http://gcc.gnu.org/ml/gcc/2005-06/msg01238.html
> 
> Just so other beside Guido see those.

This discussion just highlights how different the perspective of much of
the C community (especially its language committee and compiler writers)
is on error handling and language safety, relative to the perspective of
the community that uses Python and other memory-safe languages.

The C perspective is that programs have to be correct, and if they're
not correct, it basically doesn't matter what happens.

The safe language perspective is that of course we try to write correct
programs, but if a program is not correct, then it *really matters* what
the error behaviour is. Ideally, it should be something that facilitates
debugging and that doesn't silently propagate an incorrect result.
Undefined behaviour is right out.

For example, from <http://gcc.gnu.org/ml/gcc/2006-08/msg00522.html>:

# The gcc developers always face two competing constituencies: do not
# change the compiler behaviour so that existing code which relies on
# undefined behaviour continues to work, and do change the compiler
# behaviour so that new code which does not rely on undefined behaviour
# runs faster.  In general, being compiler developers, we come down on
# the side of making code which does not rely on undefined behaviour run
# faster.

... and rarely even consider whether the behaviour *should* have been
undefined or not.


(There are many people who use C but do not agree with that perspective
on error handling -- I'm one of them. These people often devise elaborate
error handling frameworks, and compile at low optimization levels when
it doesn't hurt performance.)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>