Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <11008@smoke.BRL.MIL>
Date: 9 Sep 89 06:00:32 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <19474@mimsy.UUCP> <9278@attctc.Dallas.TX.US>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <9278@attctc.Dallas.TX.US> chasm@attctc.Dallas.TX.US (Charles Marslett) writes:
>Because one special invalid pointer has to be acceptable in all expressions
>except dereferencing (NULL, that is), ...

No!  Null pointers do NOT have to be represented by invalid addresses.
They merely have to be distinct from any address of valid objects that
a strictly conforming C program could access.  There are no performance
penalties required to implement null pointers even in an architecture
that traps on loading invalid addresses.

>Why don't we just say is it lousy looking code that does this sort of thing --
>so don't do it (even though it will work 99999 times out of 10000, or whatever
>the fraction really is.

Good advice; since it is not necessary to rely on the nonportable
ability to continue to play with a pointer after it is free()d,
it is best to simply avoid doing so.