Re: [c++] bug 2628 and new

[Mike Stump <mrs at windriver dot com>]

> Date: Thu, 26 Apr 2001 16:00:53 +0100
> From: Nathan Sidwell <nathan@codesourcery.com>
> To: gcc@gcc.gnu.org

> bug 2628 concerns operator new indicating failure by returning NULL, and
> -fno-exceptions.

This is not a bug, rather, user confusion.  new is not allowed to
return 0 according to the standard.  If they _must_ do this, then they
_must_ declare new before use, with throw(), or use -fcheck-new.

> The user had turned off exceptions with -fno-exceptions and expected
> operator new to indicate failure by returning NULL. What should the
> expected behaviour be?

new needs to do the equivalent of throw.  If there isn't a way to
catch, then it is logically equivalent to abort.  If the user wants to
see 0, they need to call new nothrow.  A simple #define new new
(std::nothrow) can get them most of the way there in legacy code, and
a simple audit can get them the rest of the way there.  I recommend
that.

To be concrete:

#include <new>

#define new new (std::nothrow)

void main() {
        int * ip = new int;
}

> 1) we could turn on -fcheck-new when -fno-exceptions is enabled. The
> user must replace the system provided operator new.

No, -fcheck-new should not be turned on automatically.  That flag is
vile is a a last chance option for people dealing with legacy code
they don't want to fix.

> 2) we could call operator new (std::nothrow) in place of operator new ().

I like the current behavior.

> 3) we could issue a diagnostic when -fno-exceptions is enabled an
> operator new is called (and any other throw expression?)

We used to issue a diagnostic when new returned 0...  

> thoughts?

Shoot the user.