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 --------------------------------------------