Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh
From: mccaugh@s.cs.uiuc.edu
Newsgroups: comp.lang.pascal
Subject: Re: FreeMem, GetMem & TP50
Message-ID: <208300013@s.cs.uiuc.edu>
Date: 22 Aug 89 23:50:00 GMT
References: <1392@lafcol.UUCP>
Lines: 10
Nf-ID: #R:lafcol.UUCP:1392:s.cs.uiuc.edu:208300013:000:644
Nf-From: s.cs.uiuc.edu!mccaugh    Aug 22 18:50:00 1989


 Upon reflection, I now realize that I spoke too soon: there is much more to
 my predecessor's point than I at first realized: if (as I strongly suspect,
 knowing Borland Int'l as I do) they support only a naive memory-manager,
 then when blocks become available whose addresses are not contiguous (this
 is what I mean by NAIVE), they cannot coalesce the block with existing heap
 so they (naievely) plant a pointer to it and charge the user for 8 bytes of
 space: 4 bytes for the pointer (address) and 4 for the block-size, which 
 would explain the discrepancy. This does indeed constitute a very valid
 indictment of the Borland approach!