http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
Bug #: 56126 Summary: -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bruck.mich...@googlemail.com Code generated with -fno-exceptions active does not check for nullptr on return from operator new unless throw() is specified. In code compiled with -fno-exceptions nothing can be thrown, consequently all new operators should imply throw() or a warning/error should occur when new operators without throw() are used. $ cat test.cpp #include <stdio.h> void * operator new(size_t size) //throw() { return 0; } struct foo { virtual void dummy() {} }; int main() { foo * f = new foo(); printf("f = %p\n", f); } $ gcc test.cpp -fno-exceptions -fno-rtti test.cpp: In function ‘void* operator new(size_t)’: test.cpp:5:12: warning: ‘operator new’ must not return NULL unless it is declared ‘throw()’ (or -fcheck-new is in effect) $ ./a.out Segmentation fault (core dumped) The compiler diagnostic only appears because this example is reduced and the compiler can evaluate the return value at compile time. In real-life the compiler will generate code that assumes that all new errors return as exceptions even though exceptions are disabled. The example crashes when the vtable pointer is written, likewise but not shown here the compiler calls the constructor with this == nullptr.