Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-unix!hplabs!nsc!nsta!instable!amos
From: amos@instable.UUCP
Newsgroups: comp.arch
Subject: Re: Anecdote about dereferencing null pointers (was catering to bad code)
Message-ID: <701@instable.UUCP>
Date: Tue, 24-Feb-87 03:15:16 EST
Article-I.D.: instable.701
Posted: Tue Feb 24 03:15:16 1987
Date-Received: Fri, 27-Feb-87 01:12:23 EST
References: <14833@amdcad.UUCP> <428@omepd>
Reply-To: amos%nsta@nsc.com (Amos Shapir)
Distribution: world
Organization: National Semiconductor (Israel) Ltd.
Lines: 20

In article <428@omepd> jimv@omepd.UUCP (Jim Valerio) writes:
>On modern systems with memory management, the equivalent of this
>problem might be a program that references unused memory at the end of
>the last allocated page, counting on it to be zero.  The lesson is that
>any pointer, and not just null pointers, might mistakenly count on
>dereferencing to return 0.  I wouldn't be surprised is there are many
>programs with off-by-one errors that have this behavior.

Some known bugs of that nature:
- the vanilla 'curses' library has exactly such a bug.
- the BSD4.2 keeps a 'red zone' protected page to guard the end of the kernel
 stack, but it's in the wrong place. (I dont think any configuration has
 ever overflown the stack into the red zone, though).
- The Bourne shell has a bug that crashes only on systems that do not have 0
 in location 0 *and* clear released memory pages.
-- 
	Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel
(011-972) 52-522261  amos%nsta@nsc.com 34.48'E 32.10'N