Path: utzoo!attcan!uunet!decwrl!ucbvax!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: What machines core dump on deref of NULL?
Message-ID: <1990Jun29.132304.12550@athena.mit.edu>
Date: 29 Jun 90 13:23:04 GMT
References: <444@mtndew.UUCP> <31079@cup.portal.com> <13226@smoke.BRL.MIL> <412@minya.UUCP>
Sender: news@athena.mit.edu (News system)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 31

In article <412@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
|> Hey, wait just a minute here.  I can't let such an erroneous error go
|> unchallenged!  Dereferencing a null pointer is quite definitely *not*
|> an error, bug, mistake, or any other pejorative, in a great many sorts
|> of applications.
|> 
|> The trouble with generalizing to all C code is that C outgrew Unix
|> about a decade ago.

  From K&R Second Edition, Page 102: "C guarantees that zero is never a
valid address for data, so a return value of zero can be used to signal
an abnormal event, in this case, no space."  ANSI C is a lot newer than
"about a decade ago." 

  If you use a compiler that allows 0 to be a reference to valid data,
then your compiler is non-standard.  There may be situations (such as
the one you described in your posting) in which such a non-standard
configuration is desired, but just because it's desired doesn't mean
it's valid standard C.

  It would seem to me that a simpler solution to the embedded processor
problem than requiring a non-standard C compiler in order to write code
for one would be to not have any physical memory at address 0, or to put
program memory there (since, unless the program is self-modifying, it
should never have to access its own memory, excluding perhaps function
pointers).

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710