effect of free()

[Tim McDaniel]

In article <1010 at m3.mfci.UUCP> karzes at mfci.UUCP (Tom Karzes) writes:
> Nonsense.  There are no indirect or indexed references in the code
> above, hence no opportunities for invalid address traps.

*sigh*  It goes around and around, and people keep not understanding ... 
A machine is permitted (by pANS C) to signal an error in other cases
than dereferencing.

An anology: there are machines that have rigorous checks on
floating-point numbers.  For instance, if you use an IEEE
"not-a-number" (any of a number of possible bit patterns), it may
signal an error.  It may even fault if you just load the value into a
register.  Even if you don't use it in a computation, the system
"knows" that it couldn't possibly be a valid floating-point number,
and signals an error when you just try to load it or store it.

There are machines that work the same way with addresses.  For
example, it may determine that page 0xf350 is not in your address
space, so no pointer that starts with 0xf350 can possibly be valid.
Such machines can fault if you use the pointer IN ANY WAY --
dereference, of course, but ALSO if you perform pointer arithmetic, or
pointer comparison, or EVEN JUST COPY IT into or out of an address
register.  This implementation may be lousy, but it exists, and it
conforms with pANS C.  (At least, it's permitted to exist; I'm not
personally familiar with any such systems, but I heard that they do
exist.)

> Sorry, but NULL is no more valid than the pointer returned by malloc.

It is not valid to dereference NULL, but it is permitted to assign it
to a pointer variable and to compare it to a pointer.  It is invalid
to do these two things to a free()d pointer (although most systems
will actualy permit it).  In that sense, NULL is more valid than a
free()d pointer.
-- 

\    Tim McDaniel       "Tim, the Bizarre and Oddly-Dressed Enchanter"
 \   Internet: mcdaniel%astroatc.uucp at cs.wisc.edu
/ \  USENET:   ...!ucbvax!uwvax!astroatc!mcdaniel