Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!bbx!bbxeng!scott
From: scott@bbxeng.UUCP (Engineering)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <254@bbxeng.UUCP>
Date: 8 Sep 89 23:21:30 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> <10817@riks.csl.sony.co.jp>
Reply-To: scott@bbxeng.UUCP (Scott-Engineering)
Organization: Basis International, Albuquerque, NM
Lines: 43

In article <10817@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
>bill@twwells.com (T. William Wells) writes:
>
>
>To cover all cases though:  IT IS MADNESS TO DO ANYTHING WITH A FREED
>POINTER.
>

I figure it is time someone kind of summerized the different points
people have been making in this thread in order to reduce future
use of bandwidth on this topic.

1)  A free()'ed pointer may or may not be pointing to a valid memory
    location.

2)  It is possible that the freed memory block has been returned to the
    system and is no longer in the process's address map.

3)  Therefore, to de-reference such a pointer might cause a trap.

4)  However, on some architectures (i.e. 80286), to merely *load* an
    invalid address *without* de-referencing it could still cause a
    trap.  So, a simple compare operation on an invalid pointer is
    not always safe.

5)  However, a C compiler that attempts to load a segment register (or
    overly sensitive address register) in order to simply *compare*
    addresses is brain damaged.

6)  Therefore, we all agree to avoid those compilers thus driving the
    vendors out of business and we have nothing to worry about.

7)  A list of such vendors would be most welcome so we can begin our
    boycott.  :-)

How about it, folks?

-- 

---------------------------------------
Scott Amspoker
Basis International, Albuquerque, NM
505-345-5232