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

Jim Larson larson@kesey.jpl.nasa.gov
Wed, 29 May 1996 18:25:01 -0700


In message <9605292119.AA08179@geodesic.com> Charles Fiterman writes:
>Jim Larson writes:
>>Charles Fiterman writes:
>> >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 difference is loose pointer bugs.

Ah, so by "actual free()" you must mean reclaiming the old storage area
without doing a full collection.  Sure, then you break your collector
by not tracing live data first.

>> 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.
>
>Yes but we were discussing C and C++. Eiffel, Scheme, CLOS etc don't
>have realloc() either.

Well, you *can* have a precise collector for portable C, although you
need to control the compiler too, and it would break most vernacular C
code.

>> >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!
>
>Nope. The original K&R C said that if you free an object you can use it
>safely until the next malloc(). This ignores threads and many implementations
>ignore it but much code has stuff like.

Hmm.  Maybe you can please everyone by having an "uncover latent bugs"
version of the library and a "run regardless of bugs" version?

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