Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!usc!cs.utexas.edu!uunet!ibmpa!bass.tcspa.IBM.COM!webb
From: webb@bass.tcspa.IBM.COM (Bill Webb)
Newsgroups: comp.unix.wizards
Subject: Re: Referencing NULL pointers
Message-ID: <1501@ibmpa.UUCP>
Date: 21 Jul 89 23:03:38 GMT
References: <1989Jul14.092231.24845@inquiry.org> <19367@paris.ics.uci.edu> <10515@smoke.BRL.MIL> <168@jma.UUCP>
Sender: news@ibmpa.UUCP
Lines: 28

In article <168@jma.UUCP> max@jma.UUCP (Max Heffler @ Landmark Graphics) writes:
>
>The IBM RT PC still allows deferencing on null to be "benign".
>This has caused us a fair amount of grief when porting from the RT.
>-- 
>Max Heffler                     uucp: ..!uunet!jma!max
>Landmark Graphics Corp.         phone: (713) 579-4751
>333 Cypress Run, Suite 100
>Houston, Texas  77094

For record, on the RT/PC BSD 4.2 port there were two factors that
influenced the decision on what * (char *) 0 should do. One one hand we
were concerned that programs that had this sort of construct that "ran"
on the vax (that most people were using to run 4.2 BSD at that time)
would complain when the same code core dumped or failed on the RT. We
were also concerned at the time it would take to find and fix all such
code in the various utilities. On the other hand we thought that the
code with such constructs was buggy and should be fixed. In the end we
arranged that *(char *)0 would return 0 (this took a bit of effort as
execution started at zero, but it turned out that I found an
instruction that had a zero in the right place and used that).  In
retrospect I think we probably should have gone the other way on this;
or at provided a way to test code with different behaviour.

----------------------------------------------------------------
The above views are my own, not necessarily those of my employer.
Bill Webb (IBM AWD Palo Alto), (415) 855-4457).
UUCP: ...!uunet!ibmsupt!webb