Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <29113@news.Think.COM>
Date: 9 Sep 89 18:48:17 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <10984@smoke.BRL.MIL> <2069@munnari.oz.au>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 22

In article <2069@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>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.

I was almost going to answer that I couldn't think of any, but then I
thought of an easy way to implement it.  The machine is one where
loading invalid pointers causes a trap, and where pages or segments
have access modes.  The null pointer would then be implemented as a
valid pointer to a page whose read and write bits were both off.
Loading the null pointer into an address register would not cause a
fault, but indirecting through it would cause a protection violation.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar