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.