Path: utzoo!attcan!uunet!bloom-beacon!think!ames!ncar!unmvax!bbx!bbxsda!scott From: scott@bbxsda.UUCP (Scott Amspoker) Newsgroups: comp.lang.c Subject: Re: effect of free() Message-ID: <154@bbxsda.UUCP> Date: 22 Sep 89 16:27:54 GMT References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM> <248@seti.inria.fr> <246@ssp1.idca.tds.philips.nl> <21952@cup.portal.com> <10983@smoke.BRL.MIL> <591@augean.OZ> <125@bbxsda.UUCP> <11121@smoke.B Reply-To: scott@bbxsda.UUCP (Scott Amspoker) Organization: Basis International, Albuquerque, NM Lines: 33 >: It's not very hard to factor in the notion that a pointer is "poison" >: when it no longer points to valid storage. One would think that >: "well-written code" would already follow that model, which is >: compatible with a wider range of environments. >Mine always did. Even before I learned to think about portability. It ^^^^^^^^^^^^^^^ >just never occured to me that a freed pointer was anything but >nonsense. How do you know? Although a bad example using the free() call was what started all of this the discussion has turned to the more general problems of handling pointers. I don't doubt that your calls to free() are clean. What about every other place that pointers are used? How many other programmers are working on your project with you? If you did handle a bad pointer at one point (even though program logic would not deference that pointer under those conditions) how would you know (without personally examining every line of code)? Chances are your machine is allowing it so there would be no trap generated. This isn't a flame. :-) :-) <- see, I'm smiling It's just that there is a lot more at issue here than a call to free(). There is a comment above about being compatible with a "wider range of environments". Since nobody has yet given a real world example of "pointer poison", just how much "wider" a range are we talking about? -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232