Path: utzoo!attcan!utgpu!watmath!att!dptg!rutgers!usc!gem.mps.ohio-state.edu!wuarchive!cs.utexas.edu!mailrus!ames!ncar!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <137@bbxsda.UUCP>
Date: 21 Sep 89 16:44:51 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: 49

In article <11121@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
 >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.


You missed the point of my posting.  Someone else recently made
an excellent posting on this issue (I forgot who, sorry).  It
was pointed out that there are no new portability issues that haven't
been there all along.  In other words, this pointer thing is not new.
However, nobody has been able to come up with an example where this
was actually a problem (unless I missed something).  Maybe it is 
because of the way people write their programs.  Maybe it is because
C implementers didn't have a standard to hide behind and kept a wide
safety margin in their products.  

Now that certain things are being *officially* declared as "implementation
dependent" there is a potential that things could be abused.  The implementer
only needs to tell everyone that their code is improperly written.  That
implementer only needs to hope that his competitors are equally arrogant.

There is currently a thread over in comp.std.c asking the question 
"Do non-trivial conforming programs exist?"  That is a valid question.
My point was, "As long as you are running on a sufficiently wide range
of environments (assuming that is your goal) who cares if fail on, say,
1 out of 20.  Sometimes the reason is simply and you should go ahead
and make the necessary change.  Other times the change would go far
deeper into the code and cost to much to change.

My alarm went off when I used the term *well-written code* in my
previous posting.  I was opening a can of worms but I did it
anyway because I *really* meant it.  There is *well-written* code
out there that is not necessarily 100% conforming.  Some people
may argue that I am stating a contridiction.  It all depends on
how you measure it.  If the code work is clean, maintainable,
effecient, and runs on "wide range of environments" (subjective)
then it is probably pretty good stuff.  Yet it might not be 100%
conforming.  The company's bottom line is the final arbitrator.
-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232