🚀 go-pugleaf

The history so far: the issue is the fact that g++ does not generate
a test for operator new() returning 0 before invoking the constructor
in an expression

	new Foo

where Foo has a constructor.  The reason for this is to generate more
efficient code; the new_handler function can be used to trap on
out-of-memory conditions for the common case where all you can do when
memory runs out is quit.

Unfortunately, in some applications, especially those where special
storage allocators are written, memory running out is an expected and
recoverable condition and the ARM behavior of having "new Foo" return
0 without a call to the Foo constructor is what is wanted.

Mike Stump says that the ANSI C++ committee is considering forbidding
operator new from returning 0, requiring the throwing of an exception
instead.  I agree that this is the correct long-term solution, but we
do not currently have exceptions.

Eric Valette complains bitterly about all this.

Darrin West posted a patch to generate a test for operator new returning
NULL, but only for the scalar case; the code to do the vector case, e.g.
new Object[some_number], is similar.

Darrin writes:

>I suppose the exception handler could just as easily handle the error, but
>it sure seems like a large amount of work to set up an exception and catch
>it when a simple test can work.

The main advantage to exceptions vs "a simple test" is that the exception
is always thrown, while it's quite unlikely that programmers will test
every single "new" for a zero return value.  Exceptions can also be
caught several layers up, immediately surrounding the new call, or
allowed to terminate the program.

>I expect I have raised a few people's hackles here.  Apologies.  We needed
>a solution immediately and needed it to work for both cfront and g++.

On the contrary, you've done exactly what benefits the community most;
rather than just bitch about a problem you've done something about it.
Thank you.  Now where do we go from here?

I think that a good interim solution, until the language has exceptions
or the ANSI committee decides the issue, is to make the generation of the
test conditional; if the user supplies

	-ftest-new

then the compiler will generate code to test the result of operator new;
if not, the test will be omitted.  Most programs on Unix systems will
benefit by omitting the test and using new_handler to print an error
message and exit should memory run out; it would also be possible to
compile some modules with the flag and some without, for the optimal
combination of speed and safety.

I don't know what the exact philosophy behind what the "-ansi" and
"-pedantic" flags are, but as far as I know, the requirement to test
the return value of "new" is still in the draft (correct me if I am
wrong), so at least for now, perhaps "-pedantic" could turn on this flag;
maybe "-ansi" could as well.  This would imply that "-fno-test-new"
would turn the flag off.

Comments?  If there's interest, perhaps when I get some time I'll try
hacking it in, or perhaps Darrin might want to, or "Let's get Mikey
[Stump] to do it, he hacks everything" :-)

--
Joe Buck	jbuck@ohm.berkeley.edu