Path: utzoo!mnetor!uunet!husc6!ukma!nrl-cmf!ames!killer!richardh
From: richardh@killer.UUCP (Richard Hargrove)
Newsgroups: comp.lang.c
Subject: Re: Is &a[NTHINGS] legal
Message-ID: <4023@killer.UUCP>
Date: 8 May 88 14:41:50 GMT
References: <12074@tut.cis.ohio-state.edu>, <10716@steinmetz.ge.com> <1988May5.194916.1971@utzoo.uucp>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 24
Summary: segmentation violationsand the 80386

In article <1988May5.194916.1971@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> This isn't imaginary.  I know of at least one machine (not a common one)
> in which pointer arithmetic was strictly offset arithmetic, with no carry
> into the segment part; I don't remember whether overflow was trapped.
> 

This will be the case in the most useful operational mode of a soon-to-be
very common architecture: protected, USE32 mode of the 80386, where segments
have a maximum limit of 2^32 btes but generally have much smaller actual
limits (maintained in the segment descriptor). Bound checking code will 
have to be VERY complicated to keep from generating an exception if a 
computed offset exceeds the segment limit (the limit must be read from the 
segment descriptor entry in the GDT or LDT, neither of which was designed
to be accessible from the user's code). Or else a 4 gigabyte limit must be
installed for every defined segment, which seems both unlikely and self-
defeating.

For what it's worth, the Intel 80386 tool, bnd386, adds pad bytes at the
end of defined segments to ensure, among other things, that a reference
such as a[NTHINGS] will NOT generate an exception (however a[NTHINGS+1]
may, depending on sizeof(a[0]) and segment alignment requirements).

...!{ihnp4 | codas | cbosgd}!killer!richardh
--------------------------------------------