Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.lang.c
Subject: Re: Contiguous Arrays
Summary: Where did we fall into such trash?
Message-ID: <7309@killer.DALLAS.TX.US>
Date: 25 Feb 89 05:03:50 GMT
References: <2508@ssc-vax.UUCP> <8943@alice.UUCP> <1828@valhalla.ee.rochester.edu> <7799@sneaky.TANDY.COM>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 97

In article <7799@sneaky.TANDY.COM>, gordon@sneaky.TANDY.COM (Gordon Burditt) writes:
 > >On a similar note, just yesterday a friend and I were discussing
 > >tricks to access arrays with different ranges.
 > >For instance, if the array was to be x[101] to x[110] instead of
 > >x[0] to x[9], what is the easiest way to do it?
 > >For automatic arrays one could do
 > >int space[10], *x; 
 > >x = &space[0] - 101;
 > 
 > UNPORTABILITY ALERT!
 > 
 > There is no guarantee that there is a way to represent &space[0] - 101
 > at all.  Further, computing it may cause overflows such that
 > 
 > 	(&space[0] - 101) + 101 != &space[0]

Please explain?  What machine does this, or what architecture would allow
the machine or programming language to do it?

 > It could happen that (&space[0] - 101) == (int *) NULL.  Even computing
 > &space[0] - 101 could cause core dumps (MSDOS equivalent:  hang system
 > forcing use of RESET, optionally trashing FAT on hard disk)

This is not necessarily a condemnation of any computer that shows such lack
of concern for basic mathematics, but I would expect a computer that does
anything but return equality in the above expression to be broken as a
mathematical engine.  If it is acceptable for addition and subtraction to
be other than inverse operations (taking into account the possibility of
an error trap or whatever) the thing you are using cannot support any
programming language I know of without simulating integer arithmetic with
some well protected external unit.

And to address the question of errors, if we limit arithmetic to addition
and subtraction of integer quantities, any computer that supports both
signed and unsigned arithmetic will have to be able to generate the result
of that expression without a fault or even an excessive number of machine
cycles wasted.  To make it even more serious, I do not know of any twos-
complement computer that even has a signed vs. unsigned add instruction.

So I have convinced myself that if this is really a problem it is a failure
of the compiler (over optimization or use of a specialized instruction that
really is inadequate?).  Can anyone get a bit more explicit about how this
bit of "fiction" in the addressing of an array fails on any computer, anywhere?
It works on the compilers I know of for everything from 1802s (with no real
ALU to speak of) to IBM mainframes (if you are careful) to dozens of minis.
The only well know segmented architecture it might fail on is Burroughs', and
I say that only because it is the only one I know of that I don't know anything
about ... ;^).

Or did I completely miss the point (are addition and subtraction not required
of computers in these RISCy days?)???
 > On *86 machines, consider what happens when space starts within 100
 > bytes of physical address 0.  Having it within 100 bytes of the data
 > segment origin may cause problems also.  These problems may vary with
 > model, load address, and the phase of the moon.
 > 
 > Given the declaration:
 > 	int	space[10];
 > then
 > 	&space[i]
 > has guaranteed meaning when i = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10, and 
 > no other values of i.  You can't use space[10] because it's out of range, 
 > but &space[10] is guaranteed to have a representation by the ANSI standard.

Here I agree, the standard (and most earlier compilers) guarantee you can use
&space[10], but in some cases I would bet this is not implemented (say in an
Intel box, where space is an integer array space[32768]).  &space[11] is not
required to be representable by the standard.  It just seems to be nearly
impossible to prevent it from being representable without exerting extra
effort.

 > 
 > 	struct foobar space[10], *x;
 > 	/* Right */
 > 	for (x = &space[0]; x < &space[10]; x++)
 > 		x->data = 0;
 > 
 > 	/* Wrong - this loop may never execute */
 > 	for (x = &space[9]; x > &space[-1]; x--)
 > 		x->data = 0;

This particular problem seems to me to have nothing to do with whether
space[9-9] is the same as space[0] or not.  That is, to speak more
precisely, (space-9)[9] is the same as space[0].

 > . . .
 > 
 > 					Gordon L. Burditt
 > 					...!texbell!sneaky!gordon

Charles Marslett
===========================================================================
[Former mathematician, former compiler writer, former ...]
Charles Marslett
STB Systems, Inc.  <== Apply all standard disclaimers
Wordmark Systems   <== No disclaimers required -- that's just me
chasm@killer.dallas.tx.us