Xref: utzoo news.admin:3933 news.software.b:1745
Path: utzoo!attcan!uunet!peregrine!elroy!forsight!jato!herron!herron.uucp!jbrown
From: jbrown@herron.uucp (Jordan Brown)
Newsgroups: news.admin,news.software.b
Subject: Re: bugfix for inews (control messages cause coredump)
Message-ID: <8@herron.uucp>
Date: 9 Nov 88 04:13:36 GMT
References: <5686@fluke.COM> <5695@fluke.COM> <6266@claris.com> <25995@tut.cis.ohio-state.edu> <252@obie.UUCP>
Reply-To: jbrown@jato.jpl.nasa.gov
Lines: 31
In-Reply-To: <252@obie.UUCP>

> [test pgm works in small model, not in large model]

> Neat, huh?  This is why: using the small memory model (the default),
> pointers are 16-bit offsets into the data segments.  Addresses DS:0 and
> DS:1 are valid, writable addresses, so the program runs correctly in
> small model.  In the large model, however, pointers are 32 bits, and
> include the segment selector.  This makes (char *)0 equal address 0:0,

So far so good.

> which may or may not be a valid address in the process' space.  If it is
> a valid address, it is probably in the code segment, which CANNOT be
> writable on the '286.

Segment 0 is NEVER valid.  Guaranteed.  (Amazing, Intel doing something
right!)

> This system can really be a nightmare to port to!

Not if your code is portable.  The only real problems come if you use sbrk
to allocate memory instead of malloc, or if you want to work with single
objects (arrays, structures, etc) bigger than 64K.  In general, you can't
assume anything about pointers to different objects.

We found a lot of bugs by running things under 286 large model...

(Don't get me wrong.  All in all I'd rather have a conventional
addressing model, as long as address 0 is mapped out, code is read-only,
and nonexistant memory causes faults.  Unfortunately, few versions of
UNIX choose to do all of these "obviously right" things.  It's hard not
to on a 286 in large model.)