https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
--- Comment #9 from Michael Bruck <bruck.michael at googlemail dot com> --- > Jonathan: Using -fno-exceptions says "I do not want ISO C++" so quoting the > standard isn't very relevant. > Olaf: No, as you could (should?) abort/terminate instead of returning NULL. I quoted it to illustrate that returning NULL is the intuitive option here, while abort() is a completely new approach. Returning NULL is what I would expect to be the case when -fno-exceptions is active and it is what happens in the libc++ implementation AFAIK. > Why would you want an operator new that can't throw but is declared to > potentially throw? Because -fno-exceptions suggests to the user that they can produce safe code without using any exception-specific C++ syntax. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html "The last language feature needing to be transformed by -fno-exceptions is treatment of exception specifications on member functions. Fortunately, the compiler deals with this by ignoring exception specifications and so no alternate source markup is needed." If the authors of the libstdc++ docs get this wrong, how is the average compiler user expected to know this? Likewise GCC's documentation also pretends this case doesn't exist: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/C_002b_002b-Dialect-Options.html "-fcheck-new Check that the pointer returned by operator new is non-null before attempting to modify the storage allocated. This check is normally unnecessary because the C++ standard specifies that operator new only returns 0 if it is declared ‘throw()’, in which case the compiler always checks the return value even without this option. In all other cases, when operator new has a non-empty exception specification, memory exhaustion is signalled by throwing std::bad_alloc. See also ‘new (nothrow)’. " > The exception specification is defined by the language to inform the compiler > whether to check the result or not, so use that. > If declaring it like that really isn't possible, then you should use > -fcheck-new, but it seems OK to not enable that automatically and rely on > correct exception specifications. As you pointed out we are outside the standard with -fno-exceptions. There is certainly no rule that prevents the compiler from issuing a warning when it generates code that is highly unlikely to be safe.