Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ames!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <29110@news.Think.COM>
Date: 9 Sep 89 18:23:07 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> <172@cpsolv.UUCP>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 28

In article <172@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes:
>The pointer comparison context is fundamentally
>different from the pointer indirection context; the former should be able to
>work with invalid pointer values (at least when the comparison is to NULL)
>while the latter may fault.

Why do you feel that comparing an invalid pointer to NULL is some sort
of special case?  If it were required not to fault, it would also
probably not be equal to NULL.  I imagine that code that begins with
"if (ptr != NULL)" is likely to go on to dereference the pointer (why
else would it bother checking the nullness?).  So what's the point of
making the comparison valid?

What may be needed to satisfy everyone is a built-in operation that
tells whether a pointer is valid to use.  It would have to be an
operator, not a function, so that it could get around the invalidity
of accessing freed pointers.  The definition of it would have to be
loose enough to permit efficient implementation on systems without
memory protection hardware (you don't want it running through malloc's
data structures to see whether it points into an allocated or free
block).


Barry Margolin
Thinking Machines Corp.

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