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