Path: utzoo!attcan!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.lang.c
Subject: Re: validity of free() on later pointer operations
Message-ID: <1990Jul03.233255.2616@virtech.uucp>
Date: 3 Jul 90 23:32:55 GMT
References: <1990Jul3.185032.8434@indetech.com>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 34

In article <1990Jul3.185032.8434@indetech.com> schmidt@indetech.UUCP (Doug Schmidt) writes:
>	char *s = malloc (n);
>	/* ... */
>	free (s);
>	s = 0; /* Is this assignment always legal? */
>
>	I seem to recall there was a problem with the assignment to
>char *s *after* the free.  Can someone please refresh my memory
>as to what the problem was, and why it is a problem?  Would
>replacing s = 0 by s = malloc (n) have the same problem?

There is no problem with s = 0.  However on some "hypothetical" systems,
the line:

		if( s == 0 )

can cause the program to die, since you are causing an illegal pointer
to be loaded into an address register.

I don't know of any current machine where that will happen, but it
could be the case on some system in the future.  What *almost* guarrantees
that it won't cause the program to die is the fact that on most, if not
all, implementations free() does not actually return space to the
OS.

If you want to be safe an absolute 100%  of the time, don't use a freed 
pointer (including dereferencing, or comparing).  If 99.99999% saftey
is ok, then just be sure to not dereference it.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170