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

[Charles Fiterman]

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

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

Yes! I know it isn't fair but life isn't fair. People put in the garbage
collector to fix leaks and loose pointer bugs. They generally have no
usefull access to X windows source, which is there but within epsilon of 
unreadable. It has a lot of nasty bugs, but if we make those bugs crash 
the program instantly no one says "Thank you, you have done the pure 
and logical thing." They say "Your f-----g garbage collector isn't worth 
a f--k gimme my money back."

Another way to say it is when you get paid you are held 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.

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

for (p = root; p; p = p->next)
	free(p);

If you put in

#define free(p) (p = 0)

you will crash a lot of programs. So will writing a free to instantly
clear the freed object.

My first C compiler put strings in the text segment so that code like
  "Hello sailor"[3] = '\0';
Would produce a segmentation violation. We got a flood of outraged complaint 
"My program works great under the thus and so compiler but crashes on your
piece of s--t." So even though this was the implementation suggested by the
ANSI standard I had to make it a compiler option. One that few users ever
turned on. If I had it to do over again I would have never tried to even
make correct behavior an option.