The new Constructor Bomb stuff

[Mark S. Miller <vlad!mark>]

Date: Thu, 9 Aug 90 11:44:43 PDT
   From: xanadu!michael (Michael McClary)

   ... I don't see anything that would
   prevent or detect usage of the default operator new.  Since such a usage
   leaves the code vulnerable to garbage-collector heisenbugs and constructor
   failure problems, it should be a compile- or link-time error if we can
   arrange it, a run-time and xlint error if that can't be arranged.

I don't think we want to actually prevent such usage.  I expect
profiling may point us at a small number of simple classes which we
want to *carefully* write in a faster but less safe fashion--analogous
to the way we *carefully* write occasionally with wimpy pointers.
Therefore an XLint case seems the appropriate thing.  

Roland: how about we have XLint warn for any use of "new"?  XLint
would then have to accept the CONSTRUCT macros without expansion.
Later, a more sophisticated check would only notice any use of "new"
to instantiate with an un"SAFE" constructor, and would check that
routines delared "SAFE" were indeed so.  To review, a routine is
itself SAFE if 1) it doesn't BLAST, 2) it doesn't allocate, and 3) all
routines it calls are declared SAFE (if it is a constructor or
destructor, then this last condition includes superclass constructors
and destructors, even if not mentioned explicitly).

Speaking of which, another thing to have XLint eventually check for is
that all member initializers invoked from a constructor (whether
explicitly or implicitly), and member destructors invoked by a
destructor (necessarily implicitly) are all declared SAFE to avoid the
unfixable Bomb package bug.  (Actually, I only know the Bomb package
to be unfixably buggy on the construction side of this issue.
Michael, what's the story on the destruction side?)

As we currently never use non-trivial constructed members (because of
this bug), this isn't currently a consideration.  During performance
engineering phase, I expect that many Heapers that currently have
their own storage will instead be contained inside some object which
now points at them.  (There are several mooses hiding under this rug,
so don't anyone expect to be able to do this any time soon.
Especially from Smalltalk.)

Note: Roland, none of the above checks are remotely priority items.  I
originally thought we wouldn't even need to have XLint check for this
at all--we'd just grep for "new" as an identifier.  However a quick
check shows it to be a very common word in comments.

   Yes.  (But at this point in your letter it would have been good to
   describe exactly how to retire each one when it is encountered in old
   code.  Check me on this:)

Everything you asked me to check you on is exactly correct.

	   ...
	   new(...) Whatever(...)

   ... (If you have any instances
   of the [above] case we've got a minor problem...)

That case is an example where you are doing something sufficiently low
level & wierd that you should probably continue to use "new".  Even if
the constructor you are invoking is unSAFE, you can still safely
engage in this last case by manually passing a constructor bomb as one
of the arguments (i.e. by open-coding the functionality of the
CONSTRUCT macros).  

   (If you're wondering what "PLANT_CONSTRUCTOR_BOMB_NORMAL_NEW()" was
   about:  At one point CONSTRUCTOR_BOMB()s had to be upgraded to use
    "MYCLASS::operator new(sizeof(MYCLASS))" in some cases, and
    "       ::operator new(sizeof(MYCLASS))" in others.  Because the
   case using the class-specific operator was the more common one in the
   existing code, Mr Hill elected to change the name of the rarer case.)

I take it the less common case is for protecting the heap allocation
of non-Heapers?  This corresponds to a problem--the new constructor
bomb mechanism only address Heapers.  I didn't figure out how to do
otherwise.