In message <200507291149.j6TBnlgZ027690@vtn1.victoria.tc.ca>, John Nemeth write
s:
>On Dec 19,  1:08am, Peter Seebach wrote:
>} To be picky, there exist C implementations where at least some, possibly
>} all, pointers to freed space compare equal to NULL.

>} However, there also exist platforms on which any reference to them, even
>} a comparison to NULL, causes undefined behavior.

>     How can this be so?  free() is a function, not an operator.
>functions can not change the value of their paramters.

Ahh, but:

1.  free() isn't a real function, but a Library Call.  They are somewhat
magic.
2.  "The value of a pointer to free space is indeterminate."

For a practical answer to "how", imagine a segmented architecture, where
pointers indicate to which segment they point, and where in the segment.
On this architecture, there might be many possible "null pointer"
representations, and the check for a null pointer might involve checking
to see whether the segment was "valid".  If the only allocation in a segment
were freed, any pointer with that segment could legitimately compare equal
to NULL.

On a broader variety of platforms, where the MMU is used to sanity-check
things, loading an address into an address register checks it for validity,
and a freed pointer may be invalid, so you get a trap right away on access
to the value, without dereferencing it.

>     Assuming the above is true, then I would accept this; however, I
>don't understand how the above can be true.  At least not without doing
>weird things during function calls, which would break the symantecs of
>the language.

The semantics of the language are very careful to allow for Weird Stuff to
happen when pointers are freed.

(Note that automatics that have been deallocated because their allocating
scope is gone have the same trait; pointers to them can be indeterminate,
and can theoretically change without warning or cause traps.)

To be fair, in the case of NetBSD, we have some control over what the
implementation does, because we *are* the implementation... but I'd hate to
see an effort to introduce stronger pointer-checking stymied because tons
of code makes questionable assumptions.

-s