Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!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: <2069@munnari.oz.au>
Date: 9 Sep 89 11:41:31 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <10984@smoke.BRL.MIL>
Sender: news@cs.mu.oz.au
Lines: 47

In article <10984@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <2059@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
> >    Are there code sequences on trapping machiens 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.

Irrelevant.  My question explicitly pertains to implementations where
NULL is mapped to an invalid address.  Other implementations do whatever
they do; I wasn't asking about them.

> >	(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.

NO, I was asking are there code sequences for which (a) and (b) and (c)
are *ALL* true *TOGETHER*.  Yes, we have been talking about machines which
have code sequences where (b) is true.  I am asking are there code
sequences on those machines where (a) the implementor chose to make
dereferencing NULL trap, but in such a way that ptr1==ptr2 doesn't trap
on NULLs *AND* (b) the implementor chose to make comparing other invalid
addresses trap *AND* (c) under the constraint that the invalid address
chosen for NULL doesn't trap but others do, those code sequences are
faster than ones that don't trap at all.

> >	(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

On an 80*86, it is _possible_ to compare pointers using the data
[e]{a,b,c,d}x registers rather than the segment registers.  It's been a
while since I hacked 80386 code, and I've never hacked an 80286 at all,
and segment registers are not quite the same as address registers.  My
recollection is that a full pointer comparison on an 80286 would be the
same number of instructions whether you used segment registers or not,
and would be significantly faster if you didn't (precisely because you
would bypass the checking).  [I've heard stories about programs running
much slower on 80286s than 8086s because they put things into segment
registers.]  It would be helpful if someone who knows the answer for 80*86s
would post it.