Date: Tue, 16 Oct 2001 10:29:41 -0700 From: Joe Kelsey <joe@zircon.seattle.wa.us> To: freebsd-stable@FreeBSD.ORG Subject: Re: setenv() cores with NULL value [was Re: Gdm proplem on 4.4] Message-ID: <15308.28294.14549.91586@zircon.zircon.seattle.wa.us> In-Reply-To: <10872.1003237569@thrush.ravenbrook.com> References: <count@shalimar.net.au> <200110161002.f9GA2CA08544@shalimar.net.au> <10872.1003237569@thrush.ravenbrook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nick Barnes writes: > At 2001-10-16 10:02:11+0000, Zero Sum writes: > > Has this changed without me noticing? > > It was never generally true. Your memory may have its roots in the > fact that some operating systems on some machines in the early 80s > (VMS on VAXen, ISTR) wired page zero to be zero on read, discard on > write, so that you could read from a NULL pointer (which was address > zero in that -- and most -- implementations of C) and get zero bytes. > On such a machine you could indeed pass NULL to a function that was > expecting a string and get the same behaviour as passing a pointer to > an empty string. Of course, the whole reason that VAX UNIX went to the trouble of putting a zero in page zero was due to the innumerable C programs written for PDP-11 UNIX which took advantage of this accident in the PDP-11 memory mapping. It is a complete accident that byte zero of every PDP-11 data-space was a zero, thus allowing the so-called null-pointer error to creep in. I believe that the Bell Labs version of 32V and also Interdata UNIX "fixed" this problem by not mapping data page zero to force this bug to be found and fixed. The BSD people did not want to fix all of the broken programs in the world, so they perpetuated the PDP-11-induced error. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15308.28294.14549.91586>