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

[Nick Barnes]

> Charles Fiterman wrote:
> > > 
> > > 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!
> [...]
> > Another way to say it is when you get paid you are held to a higher
> > standard.
> 
> Charles Fiterman is entitled to his opinion.
> 
> However, it _is_ possible to make money in the computer
> industry without selling your soul.

It may be possible to make money by selling a C compiler which does
not adopt the million-and-one cheap hacks of previous C compilers. But
it is not possible to make money selling such a thing as a generic C
compiler, and this seemed to be Charles Fiterman's point about C
compilers. A "reference C compiler", possibly, if it has warning
messages out the wazoo.

My instincts steer me clear of writing C compilers at all :-).

Allocators are different, of course. In the world of drop-in
replacement allocators, I am convinced it is possible to make money
selling ones which break existing code which relies upon unpleasant
properties of a previous implementations, iff you have some other
added value (e.g. good debugging aids). Your market may well be
smaller. There may be other compensating properties of your market
(e.g. it may have a higher proportion of serious software engineers).

Nick Barnes