[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[bruck.michael at googlemail dot com]

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.