Horrible Aztec C BUG!!!

[Steve Kearns]

Just discovered a pretty gross bug in the Aztec C for the Macintosh.  
If anyone uses the realloc function, expect random, devestating bugs.

The realloc function is supposed to change the amount of memory gotten from
a previous malloc.  However, Aztec C (I looked at the sources, which are 
included) implements this by first freeing the old block of memory, then 
mallocing the new memory, and finally moving the old data to the new memory.
OF COURSE, ONCE A BLOCK IS FREED, ITS DATA CAN BECOME GARBAGE.  In fact
on the Macintosh a subsequent malloc call after a free often causes the heap
to be compacted, expanded, etc.. each of which can trash the data.

The reason this code is written this way is a holdover from Unix, which 
promises not to compact under certain circumstances.  

The workaround for this is to call malloc yourself, then move the data, and
finally free the old block.  The problem with this is that it requires twice
the memory of a realloc, because we have to have the old and  new blocks of 
memory at the same time.  But at least it doesn't crash.  

Their realloc routine may work as advertised on some systems;  it depends on
the internals of the Macintosh.  I found the problem when my Mac program
produced garbage at random intervals.  Implementing my workaround fixed the
problem. 

Note that Aztec C is an otherwise great package.  However, I bought the 
professional version for $500 and they didn't even include a lint.  What
a ripoff.