Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Contiguous Arrays
Message-ID: <16089@mimsy.UUCP>
Date: 23 Feb 89 06:22:38 GMT
References: <2508@ssc-vax.UUCP> <8943@alice.UUCP> <830@atanasoff.cs.iastate.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 45

In article <830@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu
(John Hascall) writes:
>How about:
>
>Assume int's are (say) 2 bytes.  Assume further that your
>machine is stupid, and all accesses must be on an 8-byte boundary. ...
>
>	address (0x01000 base):   0 1 2 3 4 5 6 7 8 9 a b c d e f 0 1 ...
>	 x[?]                     0 0             1 1             2 2
>
>A non-contiguous array, and the compiler can always generate
>
>	p <- p + 8
>
>for p++; since it knows about the 8-byte alignment business.

The trick here is that it *appears* contiguous.  You cannot tell
(without stepping outside the bounds of the C language proper)
that there are holes.

A more interesting fact is that, because of the array-of-E /
pointer-to-E conversion rule, given a declaration like

	int x[3][2];

and such a compiler, you get this layout:

	addr:	0 1 2 3 4 5 6 7 8 9 a b c d e f 0 1 2 3 4 5 6 7 8 9 ...
		---		---		---		---
		 ^		 ^		 ^		 ^
	      x[0][0]	      x[0][1]	      x[1][0]	      x[1][1]

On a more typical machine, you get:

	addr:	0 1 2 3 4 5 6 7 8 9 a b
		--- --- --- --- --- ---
		0/0 0/1 1/0 1/1 2/0 2/1

If your compiler lets you get away with writing x[0][2]---if it does
not abort with a subscript range error---it will always do it by
talking to x[1][0].  (If C did not have malloc, the compiler could
arrange things otherwise.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris