effect of free()
Richard O'Keefe
ok at cs.mu.oz.au
Fri Sep 8 21:51:36 AEST 1989
In article <247 at ssp1.idca.tds.philips.nl>, dolf at idca.tds.PHILIPS.nl (Dolf Grunbauer) writes:
> In article <2054 at munnari.oz.au> ok at 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?
More information about the Comp.lang.c
mailing list