Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mulga.SUN
Path: utzoo!linus!decvax!mulga!prl
From: prl@mulga.SUN (Peter Lamb)
Newsgroups: net.unix-wizards
Subject: Dereferencing NULL
Message-ID: <177@mulga.SUN>
Date: Sun, 27-Nov-83 23:02:55 EST
Article-I.D.: mulga.177
Posted: Sun Nov 27 23:02:55 1983
Date-Received: Wed, 30-Nov-83 02:18:49 EST
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 31

Dereferencing NULL pointers is yet another example of idiots who
write 'portable' code, assuming however, that **THEIR** machine is the
only one on which it will ever run: the same sorts of people who designed
cpio with binary headers.

Even on a VAX, dereferencing NULL will get you garbage: sure, *(char *)NULL
and *(short *)NULL return you 0, but *(int *)NULL will give you
1024528128 !!!!.

On other machines, *NULL has all sorts of diverting contents:
On our PE3200, fputs(stdout, NULL) yeilds "'xX\007", the HP9000 will
trap it (the best thing to do if possible), the results on stand-alone
68000 programs (like the kernel) have already been well canvassed.

I would suggest that the register save mask for VAX START procedures was
made 0xffff, but for sure, some cretin would make his/her program depend
on the 'fact' that *(char *)NULL was -1. (For the DEC-bound, there is NO
guarantee that 'char's are signed!!)

As a non-DEC UNIX site for the past 5 years, we have been battling
against programmers who assume all sorts of magical properties about
computers: that characters are signed, that there is some standard
order of bytes in a word, that 'int's are preordained to be 16 bits (that
shows age, now they all have 32 bits!!) and now, the latest craze is to
dereference NULL.

Like division by zero, dereferencing NULL is a ** B U G **
and SHOULD cause programs to blow up, preferably by causing an address
trap IMMEDIATELY.

	Peter Lamb, Melbourne Uni	decvax!mulga!prl