What machines core dump on deref of NULL?

[John Chambers]

In article <26878337.172 at tct.uucp>, chip at tct.uucp (Chip Salzenberg) writes:
> According to rlc at aix.aix.kingston.ibm.com (Roger Collins):
> >When a commercial computer system doesn't run a piece of software (no
> >matter how old or poorly written) that runs on other systems, the
> >computer gets the blame.
> 
> "The computer" often gets the blame undeservedly.
> 
> So what?
> 
> We should NOT make engineering decisions based on
> perceived blame.  Dereferencing null pointers is
> *illegal* and *non-portable*.

Beg to differ, but C is widely used for writing embedded code (i.e.,
code that runs standalone on a board with a processor, some memory,
and generally some other interesting hardware).  The hardware always
insists that something particular be kept in low memory.  The code
must be able to read (and often write) location zero, or it can't 
possibly do its job correctly.  This is as true of the typical Unix 
kernel as it is of any other system.  If a C compiler doesn't allow
dereferencing a null pointer, the applications that must do so due
to the hardware's requirements are rather crippled, or must be coded 
partially in some other language.

True, dereferencing a zero pointer is usually incorrect.  But "usually" 
and "always" aren't even nearly synonyms.  Until we can get the hardware 
designers to stop using address zero, we are stuck with the situation.

Anyhow, there's a universally-available tool in C for testing for
a null pointer:
	if (p == 0) ...

Now if there were only a way to test a non-null pointer for validity,
*that* would be really useful.

(This is unix.wizards?  Sheesh! ;-)

-- 
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: [I've gotta get a new one of these some day.]