Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucbarpa!fair
From: fair@ucbarpa.berkeley.edu (Erik E. Fair)
Newsgroups: net.bugs.usg
Subject: Re: Yet ANOTHER null pointer dereference problem (in "cat")
Message-ID: <10606@ucbvax.ARPA>
Date: Thu, 10-Oct-85 04:23:23 EDT
Article-I.D.: ucbvax.10606
Posted: Thu Oct 10 04:23:23 1985
Date-Received: Sat, 12-Oct-85 17:45:48 EDT
References: <2826@sun.uucp> <2620@pegasus.UUCP> <6027@utzoo.UUCP> <2859@sun.uucp>
Sender: usenet@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 37

In article <2859@sun.uucp> shannon@sun.uucp (Bill Shannon) writes:
>
>Actually, Sun made the fixes and gave them back to Berkeley, to help
>all the other poor slobs who started with 4.xBSD as a porting base.
>Berkeley was very good about taking these fixes back.  If/when we get
>a line into AT&T, we will give them the fixes too.  I hope they will
>also be willing to take back such fixes.  I strongly urge both Berkeley
>and AT&T to build their systems such that access to location zero causes
>a fault, and then fix all the bugs that turn up.

Due to various historical (hysterical?) reasons, the Dual Systems 68000
Version 7 UNIX port had an offset of 0x800000, so that doing *(0)
resulted in a quick death by SIGSEGV.

Aside from the programs which we ported that were tripped up by this,
I remember patiently trying to explain to various customers who were
porting other programs from the VAX and PDP-11 that this was not a bug
in our hardware, but actually the sins of the programmer who wrote the
program in the first place, coming home to roost. I don't think that I
managed to convince all of them...

There were two papers given at the Dallas USENIX Conference (Jan 1985)
on this general topic:

	Latent Source Bugs and UNIX System Portability
		Alan Filipski, Motorola Microsystems

	Can't Happen or /* NOTREACHED */ or Real Programs Dump Core
		Ian Darwin & Geoff Collyer, University of Toronto

Both papers are replete with examples of How Not To Do Things, cogent
observations about portability, and guidelines for good coding
practices. I recommend them highly to anyone who programs in C at any
time, regardless of whether they intend to make their programs portable
or not.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.BERKELEY.EDU