Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!ames!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <29775@news.Think.COM>
Date: 20 Sep 89 18:50:43 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>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 38

In article <125@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>In article <591@augean.OZ>  writes:
>>C used to be a language where I felt comfortable because I had a pretty
>>good idea of its basic principles...
>there is a fear that our old friend, C, has become a 
>Marxist dictator (for our own good of course).

As has been said umpteen times in this thread, C hasn't changed (at
least not in this respect).  It has always been true that the results
of handling an invalid pointer were implementation-dependent.  The
only thing that has changed as a result of the pANS is the fact that
this portability problem is now documented; it used to be an unstated
fact.

To users, the pANS isn't a dictator, it's a mentor.  It's a
portability guide.  It doesn't say "you'll go to jail if you access
pointer variables that point to freed storage".  It says that programs
that do so could encounter portability problems.  This was true before
X3J11 was formed, and they've merely acknowledged it.  Prior to
X3J11's work such programs weren't maximally portable, but you didn't
know it; the only difference is that now you know it.

About the only bad effect this point in the standard could have is
that it may give unfortunate ideas to some implementors, who might
then go out of their way to make free() do weird things.  The
lattitude exists in the standard to allow C to map into the most
natural mechanism for a system, not to encourage intentionally
confusing behavior.  Referencing invalid pointers is allowed to trap
for the same reason that positive/negative is allowed to round either
up or down (personally, I think the implementation-dependent behavior
of "/" and "%" is one of C's biggest warts, but I know that it's way
too late to change it).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar