effect of free()

[Doug Gwyn]

In article <2059 at munnari.oz.au> ok at cs.mu.oz.au (Richard O'Keefe) writes:
>1.  there are machines on which it is _possible_ to foul up like this and
>    still be legal.  But it is _advantageous_ on those machines?  That is,
>    are there code sequences which
>	(a) can handle ptr1==ptr2 where ptr1 or ptr2 is NULL and NULL
>	    corresponds to an invalid address

NULL should NOT be thought of as corresponding to ANY address, valid or
otherwise.  I've mentioned twice now in recent weeks how an implementor
can always implement null pointers in any environment where the rest of
C is implementable.  In my suggestion, a null pointer was always actually
a valid external (run-time library) object address; however in the general
case it is up to the implementor's ingenuity just how he represents and
operates with null pointers.

>	(b) can NOT handle ptr1==ptr2 where one of them used to be a valid
>	    address but isn't just at the moment

Yes, that's exactly what we've been talking about for over a week now.

>	(c) are faster or more compact than sequences which do not trap
>	    in this case?

Yes, in a trapping architecture, all pointer comparisons (for example)
would have to perform additional operations, assuming it were even
possible which it may not be, in the generated code in order to avoid
such a trap.

>2.  Is it too late to put this requirement in the standard?  Was it
>    _really_ intended that this case should be allowed to trap?

I believe it was intentional.  I know that members of X3J11 would
occasionally mention such architectures, and even more frequently
80*86 segmentation schemes, during discussions about pointer operations.