Path: utzoo!mnetor!uunet!husc6!rutgers!ames!amdcad!sun!plx!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c++
Subject: Default new_handler
Message-ID: <186@goofy.megatest.UUCP>
Date: 25 Dec 87 05:25:10 GMT
Organization: Megatest Corporation, San Jose, Ca
Lines: 30


Sigh.. I know I've been posting quite a bit of stuff lately, but I've
just got to post this one.  I am trying to cut back, honest.

Just as soon as I posted the previous letter about _new_handlers, it
hit me (BLAP!) that the scheme is flawed.  I was proposing that _new
print an error message and then exit when core is depleted and there
is no _new_handler.  Wrong.

It would be quite reasonable for some thoughtful programmer who has
read THE BOOK to write this:

	PF old_handler = set_new_handler(0);
	if( (buf = new thingy) == 0) garbage_collect();
	/* etc. */
	set_new_handler(old_handler);

And I just thwarted him.  Darnit.

So, what I think I'm going to do is to hack things up so that the
default handler is not NULL, but instead is a routine which
prints an error message and then exits.  It is still possible that someone
will write the following, presuming that their stand-alone program has
exclusive access to the _new_handler:

	if( (buf = new thingy) == 0) garbage_collect();
	
But I think I can live with that possibility.  If it is a program which
really does run out of memory from time to time, it should be caught during
burn-in.