Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!cornell!calvin.spp.cornell.edu!richard From: richard@calvin.spp.cornell.edu (Richard Brittain) Newsgroups: comp.lang.c Subject: Re: Malloc in Turbo C Message-ID: <1990Mar1.161605.19189@calvin.spp.cornell.edu> Date: 1 Mar 90 16:16:05 GMT References: <26316@qfagus.OZ> <90058.153755CMH117@psuvm.psu.edu> <52749@bbn.COM> Reply-To: richard@calvin.spp.cornell.edu (Richard Brittain) Organization: Cornell Space Plasma Physics Group Lines: 27 In article <52749@bbn.COM> pdsmith@spca.bbn.com (Peter D. Smith) writes: > >C'mon lay off the guy. Malloc and Free are tough to get right. A story: >at a previous job, we built a run time allocation checker (bounds checking, >freeing the same memory twice, freeing a pointer after incrementing it, not >freeing memory, allocation statistics... the whole ball of wax). **Every >single library** by **every single C engineer** had problems! > >Most implementations of C are screwed up: they give you a dangerous tool >but don't give you a handle on double-checking the results. > > Peter D. Smith As a side note to this side note, I'll just mention that with Turbo-C, the chances of bombing out if you try to use something from a free'd block are VERY high, since the free() routine seems to modify the contents of the block immediately. I have found cases of code ported from various unix compilers, and from Microsoft C, which had been doing this succesfully and showed up the error right away with TurboC. In one case the original author told me the bug had been there over 3 years of development, but no-one noticed on the other systems. On a pc, you have even more incentive to get it right, since getting it wrong often means reaching for the red button. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard