mcdermot@unmvax.UUCP (02/09/85)
The recent discussion on NULL pointers having the value 0 brings to
mind a problem encountered in the days of Version 6: data was loaded
at location 0 sometimes (on a PDP-11/40). If data can be at 0, then
0 can not be the null pointer if that data is to be referenced. Our
solution was to make NULL be -1. This always seemed to be better
than 0 (except that on most machines it means slightly longer code).
I haven't noticed the problem with any current software so I guess
the problem is solved (how?).
--john
--
John McDermott {gatech|ucbvax|convex|pur-ee}!unmvax!mcdermot
Univ of NM W (505) 277-4650
Albuquerque, NM 87131 H (505) 255-7796
Merry Christmas from "The Land of Enchantment"guy@rlgvax.UUCP (Guy Harris) (02/09/85)
> The recent discussion on NULL pointers having the value 0 brings to > mind a problem encountered in the days of Version 6: data was loaded > at location 0 sometimes (on a PDP-11/40). 11/40 or 11/45? The 11/40 didn't have separate I&D space, so the C startup code should have appeared at location 0, unless you were using something other than C. I don't think the problem existed for split I&D programs, either; the C startup (at least in V7 and subsequent versions, and I think it worked this way in V6 as well) for split I&D-space programs had a little one-word shim in the data space which got loaded at location 0, so that data got loaded at location 2, in effect. An early release of an unspecified manufacturer's UNIX system had the same problem, which surprised the heck out of some of our software when it got a NULL pointer it wasn't expecting. They fixed it shortly afterwards. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> (02/10/85)
The current PDP-11 UNIX C system reserves Data location 0 in the run- time startoff module (*crt0.o), thereby guaranteeing that no compiled data will be linked at address 0.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (02/11/85)
> 11/40 or 11/45? The 11/40 didn't have separate I&D space, so the C > startup code should have appeared at location 0, unless you were using > something other than C. But what about sysfix?
guy@rlgvax.UUCP (Guy Harris) (02/11/85)
> > 11/40 or 11/45? The 11/40 didn't have separate I&D space, so the C > > startup code should have appeared at location 0, unless you were using > > something other than C. > > But what about sysfix? "sysfix" made split I/D space kernels out of kernels linked with "ld" (I had all my V6 experience on non-split-I&D space machines so I don't remember too much how it worked). It wasn't used on non-split-I&D space machines, nor was it used on user-mode code. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
Paul Schauble <Schauble@MIT-MULTICS.ARPA> (02/11/85)
I though I understood the subject before the recent flurry of traffic,
but now I'm not so sure. If I may submit a quick summary:
if (pointer)
and
pointer = 0;
ARE guaranteed by the language spec to work.
function(0)
....
int function(x)
int *x;
is NOT.
Correct??
Paulndiamond@watdaisy.UUCP (Norman Diamond) (02/12/85)
> Correct?? > if (pointer) > and > pointer = 0; > ARE guaranteed by the language spec to work. > function(0) > .... > int function(x) > int *x; > is NOT. I'm sorry to add the n'th repetition of this to the net, but if this will get it over with and cut useless traffic by 50%, here goes. YES! THAT IS CORRECT! -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."