[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