🚀 go-pugleaf

In article <1989Feb1.001209.27677@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes:
>In article <25616@sgi.SGI.COM> scotth@harlie.SGI.COM (Scott Henry) writes:
>>It turns out that Manx has TWO malloc()s... 
> Unfortunately, on Unix systems, the sequence
> 
> 	free(p)
>	... operations not involving memory allocation ...
>	q = realloc(p,size)
>	
>will work, and worse still, some programs rely on this (it's even
>documented in the manual entry for realloc() on BSD and some/all
>System V systems).
>
> The good news is that few programs actually use this property of
>realloc(), and that a realloc() without this property that works with
>the standard malloc() is fairly easy to write...
>Chris Siebenmann
The bad news is that programs that rely upon this behavior are actually
very difficult to detect.  Too many UN*X programs rely upon this well
defined and almost universally supported feature.  With the Lattice compiler,
we have gon to great lengths to support this.  As you point out, it is indeed
pretty easy to write but somewhat harder to get right as there are several
subtle points to the interaction.  In fact, this also works:
    while(p!= NULL)
       {
       free(p);
       p = p->next;
       }
And is required to work for any UN*X compatible memory manager.  If you think
about it, this is actually a useful feature (but not a practice that I would
recommend) that can make coding easier when you are just hacking out a fast
solution.  I don't recommend using it but did want to point out that you 
can expect this to work on any UN*X compatible system (otherwise you may spend
a lot of time chasing some very obscure bugs).

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/