Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucsd!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <2059@munnari.oz.au>
Date: 8 Sep 89 11:51:36 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <247@ssp1.idca.tds.philips.nl>
Lines: 44

In article <247@ssp1.idca.tds.philips.nl>, dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes:
> In article <2054@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
> >It is perfectly true that loading a (formerly valid, now invalid) address
> >into an address register might cause a trap.  BUT there is no reason why
> >a compiler has to translate "if (ptr == 0)" by loading ptr into an
> >address register.  [much deleted]

> What I don't understand from the answer of Richard is that according to
> him the compiler takes care of these cases so where is our problem ?

Eeek.  I didn't say that, not exactly.  What I was basically arguing is
that NULL is a similar special case, so that it is harder for a compiler
writer to foul comparison-and-assignment-of-not-necessarily-valid-pointers
up than to get it right.  Chris Torek showed how a really nasty compiler
could indeed make a special case of NULL and still foul everything else
up, and still be legal.  In the absence of a current draft of the
standard (repeatedly paying US$70+postage out of my own pocket does not
appeal to me) I can only take his word for it.

There are two questions which remain:

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
	(b) can NOT handle ptr1==ptr2 where one of them used to be a valid
	    address but isn't just at the moment
	(c) are faster or more compact than sequences which do not trap
	    in this case?

    If the answer is "yes", then we're stuck.  But if the answer is "no",
    then there would be no harm to people writing compilers for machines
    with trapping-load-into-address-register if they were required to
    make ptr == NULL legitimate at all times if it ever was legitimate.

    I believe that it is technically possible to have a C system with a
    relocating garbage collector, so the standard couldn't require that
    other relationships which the pointer might once have had to other
    pointers should stay constant, but it does seem reasonable to keep
    ptr == NULL defined.

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