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

[Jim Larson]

In message <9605291620.AB07332@geodesic.com>you write:
>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.

realloc() is hardly a mistake.  How else would you propose to grow or
shrink a region of manually-managed memory?  If there are additional
pointers into the region then the programmer has always had to supply
some fix-up code.

>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.

Huh?  If free() is a no-op as you say, what's the difference between
freeing and not freeing?

>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.

If the programmer's pointer fix-up code is wrong, but the code still
manages to limp through somehow, it seems that replacing malloc() et.
al. with *any* different implementation, GC'ed or not, could expose the
bug.  Does a GC-based malloc() have to hold itself to a higher
standard?

Note that if the collector is precise, it can trace the heap upon a
realloc() and automatically update all pointers into the realloc'ed
region.  The programmer's pointer fix-up code will now translate into
no-ops.

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

The latter isn't obselescent, it's stone undefined!

Jim Larson                      Jet Propulsion Laboratory
james.s.larson@jpl.nasa.gov     #include <disclaimer.h>