When exceptions are implemented, my understanding is that the default
behavior of operator new is to throw an exception if memory cannot be
acquired.

Does (will) the standard specify whether this is the _required_
behavior of operator new?

To write correct code, one must know for sure whether operator new is
allowed to return anything but a valid pointer.

To write correct code *easily*, there must be exactly one way for operator
new (or any other function) to report an error.  If the standard allows
operator new to return 0, writing correct code means we will have to be
prepared for both kinds of failure reports -- 0 return and exception.
I submit this will be painful enought that many people simply won't check.

Does the standard specify the interaction between operator new and the
user-definable new handler?  Is it allowed to return without finding
more memory somewhere?  Further, is it reasonable to implement a new
handler without knowing details about how operator new is acquiring
memory?  Are such details specified?

On a related matter, does the standard specify the required behavior of
user-defined terminate or unexpected functions?  Are they allowed to
return?  If they are not allowed to return, what happens if they do
return?
--
Kevin J. Hopps                  e-mail: kjhopps@mmm.com
3M Company                      phone:  (612) 737-3300
3M Center, Bldg. 235-2D-45      fax:    (612) 737-2700
St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.

In article <3drva1$kki@dawn.mmm.com> kjhopps@mmm.com writes:
>When exceptions are implemented, my understanding is that the default
>behavior of operator new is to throw an exception if memory cannot be
>acquired.
>
>Does (will) the standard specify whether this is the _required_
>behavior of operator new?

 It is required that a non-placement, non-class new expression
throw an exception or return a pointer to a valid object. That is,
code like

 void f() {
  X* x = new X;
  x->member();
 }

is _guarranteed_ not to cause problems due to failure
of the constructor of X or allocation. Coping with constructor
failure is non-trivial for placement new, however: while in
the non-placement non-class case the system is required to
delete the allocated memory (avoiding a leak), it is not clear (yet)
how this all works with user defined placement new.

>To write correct code, one must know for sure whether operator new is
>allowed to return anything but a valid pointer.

 The intent is that this is always the case.
>
>To write correct code *easily*, there must be exactly one way for operator
>new (or any other function) to report an error.

 Operator new has to throw an exception derived from a particular
class (yet to be determined exactly).  (More usually, the new
handler throws the exception). But an error can _also_ occur in the
constructor, and it is up to you to throw an appropriate exception,
and handle it.

>On a related matter, does the standard specify the required behavior of
>user-defined terminate or unexpected functions?  Are they allowed to
>return?  If they are not allowed to return, what happens if they do
>return?

 Most of these questions are indeed answered in the Working Paper.
Those that are not eventually will be (I hope). The intent is exactly
as you say -- to ensure the client of the services has fixed guarrantees,
and to constrain user replaceable functions to ensure they must
provide the same guarrantees.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189