[Python-Dev] gcc 4.2 exposes signed integer overflows (original) (raw)

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Mon Aug 28 02:46:10 CEST 2006

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>

More information about the Python-Dev mailing list