Re: [c++] bug 2628 and new

Re: [c++] bug 2628 and new

[Mike Stump]

> 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.

Re: [c++] bug 2628 and new

[Mark Mitchell]

>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

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

    Nathan> 1) we could turn on -fcheck-new when -fno-exceptions is
    Nathan> enabled. The user must replace the system provided
    Nathan> operator new.  2) we could call operator new
    Nathan> (std::nothrow) in place of operator new ().  3) we could
    Nathan> issue a diagnostic when -fno-exceptions is enabled an
    Nathan> operator new is called (and any other throw expression?)

Jason has historically not always agreed with me on these kinds of
things, but here's my position:

  - With -fno-exceptions, we should turn on -fcheck-new, and we
    should mangle new differently, in order to force link failures
    between programs that try to call `new' between things compiled
    with and without -fno-exceptions.  (We could use `nW' instead
    of `nw' for example.)  The libsupc++ implementation of 
    `operator new' should return NULL when -fno-exceptions is used.

  - -fno-exceptions should imply -fno-rtti, therey disabling 
    non-trivial dynamic_cast, typeid, etc.

    It's silly to try to come up with enough options to do all the
    cross-products of all language dialects.  Either you want to 
    program in C++, or maybe EC++, but the burden on us of 
    supporting feature1, and feature2, but not feature3 is just	
    too excessive.

  - Any use of `throw', `try', or `catch', should be a hard error with
    -fno-exceptions.  We previously came to some consensus about this,
    and Jason persuaded me to accept leniency with
    throw-specifications in the presence of -fno-exceptions.

Did the behavior with respect to `new' change since GCC 2.95.x here?

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: [c++] bug 2628 and new

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

| [1  <text/plain; us-ascii (7bit)>]
| 
| 
| gdr@codesourcery.com said:
| > | 3) we could issue a diagnostic when -fno-exceptions is enabled an 
| > | operator new is called (and any other throw expression?)
| 
| > A pedwarn? 
| 
| I'd say that the solution should also work for the other situations 
| (at least dynamic_cast on reference can throw).

I forgot that one.  Thanks for the remind.  What should happen in
effect?   
But I suspect code which enables -fno-exceptions won't use
dynamic_cast<> on references (if not by perversion :-)

Does it worth adding a special case for non-standard use of 
dynamic_cast<> ? Jason ?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: [c++] bug 2628 and new

[Theodore Papadopoulo]

gdr@codesourcery.com said:
> | 3) we could issue a diagnostic when -fno-exceptions is enabled an 
> | operator new is called (and any other throw expression?)

> A pedwarn? 

I'd say that the solution should also work for the other situations 
(at least dynamic_cast on reference can throw). This somewhat rules
out the two first solutions proposed by Nathan.

In addition to the pedwarn, maybe there should be specific versions
of the generated code (functions) that implement new or dynamic_cast.
The code would print a message and call abort(). This is 
consistent with the behavior we have when calling pure methods.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------


-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE66FOpIzTj8qrxOU4RAnDBAJ9YkFcSxV9Ma/FoXALpUaLyUQbclACgzUyA
zhfIMOjiOHl2gmPlWSiSKHk=
=ZWJA
-----END PGP SIGNATURE-----

Re: [c++] bug 2628 and new

[Gabriel Dos Reis]

Nathan Sidwell <nathan@codesourcery.com> writes:

| hi,
| bug 2628 concerns operator new indicating failure by returning NULL, and
| -fno-exceptions.
| 
| 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?
| 
| 1) we could turn on -fcheck-new when -fno-exceptions is enabled. The
| user must replace the system provided operator new.
| 2) we could call operator new (std::nothrow) in place of operator new ().

Hmm, I would suggest calling ::operator new(std::nothrow) only if we
determine that there is no replacement and we're not ending up with a
UDT::operator new.

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

A pedwarn?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

[c++] bug 2628 and new

[Nathan Sidwell]

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

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?

1) we could turn on -fcheck-new when -fno-exceptions is enabled. The
user must replace the system provided operator new.
2) we could call operator new (std::nothrow) in place of operator new ().
3) we could issue a diagnostic when -fno-exceptions is enabled an
operator new is called (and any other throw expression?)

thoughts?


nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org