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