Xref: utzoo comp.lang.c:9601 comp.unix.wizards:8003
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Referencing through a null pointer
Message-ID: <50676@sun.uucp>
Date: 25 Apr 88 03:08:59 GMT
References: <4729@cup.portal.com> <1988Apr24.092740.8673@utzoo.uucp>
Sender: news@sun.uucp
Followup-To: comp.unix.wizards
Lines: 59

> This convention started in split-space programs on the pdp11/45 under V6,
> as an implementation accident:  the data space really did begin at 0 in
> a split-space program, so an anonymous variable was inserted there to make
> sure that no normal variable had address 0, and unfortunately said variable
> was initialized to 0.

Any split I&D program with a data+BSS segment larger than 8K could be set up to
remove 0 from the address space; just make the bottommost data page a "grow
down from the top" page and stop just before the last click.  Programs with
smaller data segments could have the BSS padded.  The same could be done for
non-split-I&D programs by doing the same to the bottommost page (text or data).
This would have introduced some extra complications; I don't know whether it
would have been worth it or not.  Old binaries would still have to have been
supported, probably.

> (I hesitate to blame Dennis in particular; he is probably responsible for
> the anonymous variable, but it would have required unusual foresight to
> predict the problems and put some strange value there instead of zero.)

Dennis sent me mail a while ago indicating that John Reiser had done a paging
32V and that it did *not* have a location 0 in the address space; he referred
to this as one of the best things about that system.  He also indicated that
this system had other interesting features, such as mapped files.  Alas, this
system never got out the door....

> Both System V and Berklix inherited the problem, but it *mostly* got cleaned
> out of Berklix by early efforts at Sun that were fed back to Berkeley.  It
> keeps creeping back, since Berklix (unlike Sunnix) does not set up its page
> map to trap accesses to location 0.  Unless it's been fixed quite recently,
> System V still has the problem, since AT&T likewise does not map out 0.

That's somewhat hardware dependent; AT&T's releases don't, but people who port
it to their hardware can.  Also, the paging S5R2.2 release had a "-z" flag to
the linker that set up a "no page 0" executable; alas, this flag wasn't the
default, so buggy programs didn't get fixed.  (I seem to remember a claim that
the '286 or '386 port of S5 has no location zero, and the Motorola 68K port may
also have no location zero; alas, none of the fixes made to programs that broke
got folded back into the mainstream S5 releases.)

> (If it comes to that, Sun would probably have preferred not to, but as I
> recall it their early hardware gave them no choice.)

Probably.  At this point, we continue it in order to catch bugs; the Sun-2,
Sun-3, Sun-4, and Sun-386i all have no location zero in user mode.  The Sun-3
and Sun-4, and perhaps the Sun-386i as well, have no location zero in kernel
mode either; this caught a number of null-pointer-dereferencing bugs in the
kernel.

I know at Computer Consoles, our 68K machine had no location 0 accessible from
user mode, because there were no separate kernel and user address spaces, the
kernel portion was read-and-write protected in user mode, and the interrupt
vector had to live at the bottom of the address space and it was considered
part of the kernel.  The same problem may have occurred at Sun.

> Patches to make 4.2 map out zero have been posted in the past; the same
> could probably be done for System V, but far more programs would break.

You bet.  Many of them *did* break when we added them to SunOS - one reason why
I wish the fixes for the '286 and 68K S5 ports had made it back into the
mainstream....