Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: What does Z["ack"] = 5 mean?
Message-ID: <8281@alice.UUCP>
Date: 9 Oct 88 02:36:35 GMT
References: <14999@agate.BERKELEY.EDU> <4700019@m.cs.uiuc.edu>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 42

In article <4700019@m.cs.uiuc.edu>, kenny@m.cs.uiuc.edu writes:
> 
> /* Written  2:54 pm  Oct  5, 1988 by merlyn@intelob.intel.com in m.cs.uiuc.edu:comp.lang.c */
> Now, you may not like the idea of the subscript transposed with the
> array name, but it is legal C.
> /* End of text from m.cs.uiuc.edu:comp.lang.c */
> 
> Since K&R are somewhat unclear on the point, some compiler
> implementors, notably Encore, have been lax about implementing
> integer[pointer] and integer +- pointer.

First edition, page 186:

	A primary expression followed by an expression in
	square brackets is a primary expression.  The intuitive
	meaning is that of a subscript.  Usually, the primary
	expression has type ``pointer to ...'', the subscript
	expression is int, and the type of the result is ``...''.
	The expression E1[E2] is identical (by definition)
	to *((E1)+(E2)).  All the clues needed to understand
	this notation are contained in this section together
	with the discussion in sections 7.1, 7.2, and 7.4
	on identifiers, *, and + respectively; section 14.3 below
	summarizes the implications.

And on page 210, in section 14.3:

	Because of the conversion rules which apply to +, if E1
	is an array and E2 an integer, then E1[E2] refers to the
	E2-th member of E1.  Therefore, despite its asymmetric
	appearance, subscripting is a commutative operation.

I don't see how it's possible to be more explicit than that.
E1[E2] means precisely the same thing as *((E1)+(E2)) and is
therefore meaningful in every context where *((E1)+(E2)) is
meaningful.  In particular, it means the same as E2[E1].
I can't see how to draw any other conclusion from the above.

Indeed, some compiler writers may get it wrong.  But don't blame K&R.
-- 
				--Andrew Koenig
				  ark@europa.att.com