[gclist] C++ realloc semantics with garbage collection.

[Charles Fiterman]

To make collection part of C++ requires more than just a __COLLECTION
macro. There is a lot of adjustment that experience shows is required.

realloc() was one of the mistakes of C which survive into C++.
The first obvious problem is it assumes the array being realloc()ed
is bitwise copyable. not likely with C++ objects.

A worse problem is what happens to the old object. realloc() defines
it as being free()ed but with collection free() translates to noop.
If there is a pointer to the old object an actual free() will translate
to a loose pointer bug.

But not free()ing is even worse. A pointer to the old object now
points to antique data which looks just like valid data. Every test
on it will show no problem but the program using it will be subtilly
wrong.

The most pure thing to do is to trash the old object writing some
pattern over it. But this makes most X windows programs crash. Users
will say I linked in your collector and now my program crashes. Showing
them that the problem is really a bug in the X Windows library does
not really make them happy. They still can't use the collector.

So the user needs control over what happens to old objects after realloc().
We find that with new programs its best to trash them hard so they can't
be used. Under old programs zeroing them seems generally best but sometimes
you must simply let them hang.

With collection I hope realloc() is declared an obscelecent construct as
well as the survival of objects after free() until the next allocation.