Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Summary: you're all right, but...
Message-ID: <2054@munnari.oz.au>
Date: 8 Sep 89 03:12:16 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <10971@smoke.BRL.MIL>
Sender: news@cs.mu.oz.au
Lines: 17

In article <10971@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
In article <246@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes:
> -I agree with Dick, as the original statement is:
> -   if (ptr == 0) ...

It is perfectly true that loading a (formerly valid, now invalid) address
into an address register might cause a trap.  BUT there is no reason why
a compiler has to translate "if (ptr == 0)" by loading ptr into an
address register.  Presumably, whatever bit pattern represents the NULL
pointer on such machines may _also_ cause a trap if loaded into an
address register (several versions of UNIX, for example, invalidate the
first page of a virtual memory precisely to catch dereferencing NULL),
so a compiler has to be prepared to handle "ptr = 0;" without loading an
invalid address into such a register.  It also has to be prepared to handle
"ptr2 = ptr1;" and "if (ptr2 == ptr1)" where ptr1 may be NULL (and thus
might cause a trap if loaded into an address register).  So what's so
special about other (pointer values that may not be dereferenced)?