is this array access portable?

[der Mouse]

>> 	for (i=2000;i>0;i--) *fp++ = something;

> This is interesting.  The answer is that the *above* is valid ANSI C,
> but the seemingly equivalent last line

> 	for (i=0;i<2000;++i) fp[i] = something;   i=0;

> *isn't* valid.

> [...] Consequently, &foo[0][50] and &foo[1][0] are equal.

They are?  Is it legal to compare them?  (Do we even know that
foo[0][49] is stored adjacent to foo[1][0], as the stuff I quoted from
the sizeof section seems to imply?  I'm not as convinced of this as I'd
like to be.  But let's ignore that for now.)

> That is, [...] at some point you have the value of &foo[0][49] in fp.
> [...].  Then you increment fp.  This increment takes it from
> &foo[0][49] to &foo[0][50], which is valid since it doesn't go more
> than one place past the end of the array foo[0].  Now ordinarily you
> couldn't indirect through this pointer value.  But in this case you
> *can*, because it is known to be equal to &foo[1][0], which you can
> indirect through all right.

That's not entirely clear to me.  Why does &foo[0][50] have to point
anywhere?  And if it does point somewhere, why must it point to
&foo[1][0]?

> I checked by email with Doug Gwyn before posting this, and he
> confirmed that there had been an interpretation ruling on this or a
> very similar case.

That's reassuring, but also somewhat disturbing, because of the
uncertainties above.  Is the text of that ruling available?

I feel somewhat more confident of my actual code, because in that case
"sometype" is "char", to which special guarantees seem to apply, due to
the existence of memset and similar functions and the grandfather
clause equivalencing void * and char *.

					der Mouse

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