prl@mulga.SUN (Peter Lamb) (11/28/83)
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
ron%brl-vgr@sri-unix.UUCP (11/30/83)
From: Ron Natalie <ron@brl-vgr> Actually, on a VAX running BSD dereferencing NULL had best give you zero. A large amount of the code depends on it (I'm not saying this is a good idea, it's just the way it is). For example, the only reason you can use a zero as an argument to IOCTL where it is expecting either a zero or a pointer to some number is not because it ever checks for null pointers but because it happens to work because *0 == 0. -Ron
dbj%rice@sri-unix.UUCP (12/01/83)
From: Dave Johnson <dbj@rice>
I don't want to start another dereferencing NULL discussion (it's a bad
idea, but too much code does it to change), but Ron Natalie's last message
contained a couple of incorrect statements that should be cleared up.
First, the different ioctl's in Unix (at least in 4.1 and System 5) are each
processed by different cases of a switch statement (one in the tty driver,
one in the tape driver in 4.1, etc). The ones that don't expect a third
argument (which can thus be zero) never reference it. They don't try to
indirect through the third argument before they find out that they don't
need it.
Also, under 4.1 at least, all the ioctl's that take a pointer to a number
for the third argument actually take an (int *). If you indirect through 0
to pick up an integer, you don't get 0, you get 14693172 or 0x08c20000.
There is a zero at address zero, but it is only 16 bits worth of zero, not a
whole integer.
Dave Johnson
Dept. of Math Science
Rice University
dbj@rice