[c++] bug 2628 and new

[Theodore Papadopoulo]

g...@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.P...@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------

[Mark Mitchell]

>>>>> "Nathan" == Nathan Sidwell <nat...@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 ma...@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com

[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?'
nat...@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nat...@acm.org

[Gabriel Dos Reis]

Nathan Sidwell <nat...@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

[Gabriel Dos Reis]

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

| [1 <text/plain; us-ascii (7bit)>]

|
|
| g...@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 ?