Path: utzoo!utgpu!water!watmath!clyde!rutgers!mailrus!ames!coherent!aimt!uunet!littlei!omepd!intelisc!joel
From: joel@intelisc.UUCP (Joel Clark)
Newsgroups: comp.bugs.sys5
Subject: Re: Funny NULL pointers: (was: awk bug)
Message-ID: <234@intelisc.UUCP>
Date: 16 Feb 88 17:08:59 GMT
References: <672@pttesac.UUCP> <3748@megaron.arizona.edu> <2161@ttrdc.UUCP> <3763@megaron.arizona.edu> <275@ho7cad.ATT.COM>
Reply-To: joel@intelisc.UUCP (Joel Clark)
Organization: Intel Scientific Computer, Beaverton, OR
Lines: 23

In article <275@ho7cad.ATT.COM> ekb@ho7cad.ATT.COM (Eric K. Bustad) writes:
>In article <3763@megaron.arizona.edu>, rupley@arizona.edu (John Rupley) writes:
>> This is a bit off the thread of the awk bug, but if the 3B20 can't 
>> handle a NULL pointer in awk, how does it handle C code like:
> [DELETED]
>Any code that does this will happen to work on a VAX running UNIX, but
>will fail on many more machines than just AT&T's 3B20.  I seem to recall
>that on some machines you will get a memory access error if you dereference
>a NULL pointer! 

Another war story regarding dereferencing NULL pointers.  I once worked on a
compiler that used the 4 bytes previous to a pointer address to validate a
pointer by putting the pointer's value there.  If the pointer had a value of
1000 decimal then location 996 would contain the value 1000.  Checking code
then did something like:  cmpl -4(r4), r4.  The checking code handled the
memory faults from this.
This worked fine until we came to a Masscomp, where 'cmpl -4(0), 0' was
a valid instruction.  Seems Masscomp uses small negative addresses to access
the FPU.  Since we did not have an FPU address -4 contained 0.  Ha Ha.

Joel Clark
joel@intelisc.com
{tektronix}!ogcvax!intelisc!joel