kearns@garfield.columbia.edu (Steve Kearns) (03/31/86)
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.