Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <11121@smoke.BRL.MIL>
Date: 20 Sep 89 19:46:38 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>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <125@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>...  This is where you forbid somebody from doing something not
>because it is wrong but because you believe it could eventually *lead* to
>something wrong.

Nobody is "forbidding" you to continue to access pointers after
they're free()d.  We're pointing out that it's not portable to do so.

>Nobody wants to be told that their well-written code will suddenly fail.

Nobody wants to hear that all the world's not a VAX, either..

I agree that there is a market issue here.  However, if you really
want to strive for widest availability of your software product,
it behooves you to pay attention to these portability matters.
Otherwise, your product will be confined to environments not too
dissimilar to the specific one that you assumed as a model.

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.