Path: utzoo!attcan!uunet!sco!chapman
From: chapman@sco.COM (Brian Chapman)
Newsgroups: comp.unix.wizards
Subject: Re: What machines core dump on deref of NULL?
Message-ID: <6917@scolex.sco.COM>
Date: 30 Jun 90 23:44:02 GMT
References: <444@mtndew.UUCP> <31079@cup.portal.com> <13226@smoke.BRL.MIL> <412@minya.UUCP> <1990Jun29.232656.20695@virtech.uucp> <1990Jun30.134000.24937@eddie.mit.edu>
Sender: news@sco.COM
Lines: 26


aryeh@eddie.mit.edu (Aryeh M. Weiss) writes:

>Under SCO Xenix V/386, 386 native 32-bit (`small' model) programs dump core 
>on NULL deref.  This is because location 0 is not allocated to the data space.
>Actually, stack grows down from 0x1880000, while static and heap storage grow
>up from this location (although this offset can be changed by a linker option).

Yes but we kluged it (for the application support reasons given previously)
So that if you referenced 0 it would be _added_ to you address space
as a readonly address with 0 in it.  So writes cause SEGV at least.

Under Unix 3.2 both text and data segments are the same piece
of memory so a more normal arrangement exist text is loaded at
0 in *the* address space, and NULL data pointers point at the
readonly text address 0  (which is not zero).

>The situation is drastically different for 286 16-bit programs under Xenix 386
>or Xenix 286.  Small model 16-bit programs do not core dump because location 0
>IS in the memory map.

Which steps were taken in libc to make sure that 0 was loaded
with 0.  Again I know this is a kluge but....  (shrug).
-- 
Brian Chapman		uunet!sco!chapman
Pay no attention to the man behind the curtain!