Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!apple!bloom-beacon!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.arch
Subject: Re: NULL pointers (was: Software Distribution)
Keywords: software distribution, null pointers
Message-ID: <12424@oberon.USC.EDU>
Date: 28 Sep 88 07:15:53 GMT
References: <978@esunix.UUCP> <3112@pt.cs.cmu.edu>
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 21

In article <3112@pt.cs.cmu.edu> bsy@PLAY.MACH.CS.CMU.EDU (Bennet Yee) writes:
>....
>blithering about universal intermediate languages and cost for checking
>every pointer reference to enforce *NULL == NULL
>....
>
>Of course, if your machine core dumps on dereferencing NULL, just trap the
>fault (SIGSEGV), check the instruction that caused the trap, and patch up
>and return if it was due to dereferencing NULL; otherwise dump core.

This is a possible solition to running software that assumes NULL can be
dereferenced on a machine that doesn't allow this, but it still leaves
the problem of getting software that assumes that a NULL pointer dereference
WILL cause an exception to run on machine that does allow NULL to be
dereferenced.  (Obviously, with much overhead, it can be checked at
every pointer dereference.)
-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request