Conformant arrays-- how to?

der Mouse mouse at mcgill-vision.UUCP
Wed May 10 19:54:47 AEST 1989


In article <4700036 at m.cs.uiuc.edu>, kenny at m.cs.uiuc.edu writes:
> [ways of handling conformant 2-d arrays, one possible way being]

> - Pass to the function (in an argument called Px) the address
>   &(x [0] [0]), and then replace all references to x [i] [j] with
>   Px [n * i + j].  How portable is this latter scheme?  I can imagine
>   some brain-damaged compiler inserting a pad of unused storage
>   between rows of the array and defeating this attempt [...].

>From the Revised Standard Bible (:-), page 204 (section A7.4.8):

	...the size of an array of n elements is n times the size of
	one element.

So, suppose we have

sometype x[m][n];

then sizeof(x) must be m*sizeof(x[0]).  Since x[0] is itself an array,
sizeof(x[0]) must be n*sizeof(x[0][0]).  We therefore can perform a
masterful feat of substitution and deduce that sizeof(x) is indeed
m*n*sizeof(x[0][0]), and that compilers are therefore not allowed to
insert (per-row) padding between one row and the next of a
multi-dimensional array.  The padding between x[0][n-1] and x[1][0]
must be exactly the same as the padding between x[0][0] and x[0][1].

The King James version (:-) contains no similar statement in the
analogous place; I didn't search the whole book.  Therefore, by
Murphy's law, there are compilers which do insert such padding, though
it's possible that restrictions elsewhere combine to similar effect.

However, consider a machine with a 36-bit addressing unit using 8-bit
chars, with the declaration "char foo[n][4]".  Is it permissible to put
each row in a separate word, wasting four bits per row and decreeing
that sizeof(36-bit-unit) is 4, with sizeof(char) being, of course, 1?
This appears superficially legal, but feels dubious - are 9-bit chars
the only way out?  (Sure, they're the only *sane* way out, I'm not
asking about that!)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu



More information about the Comp.lang.c mailing list