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