Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Bug in Green Hills compiler
Keywords: i[a] not understood
Message-ID: <482@cresswell.quintus.UUCP>
Date: 19 Dec 87 01:56:56 GMT
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 39

According to the UNIX System V Programmer's Guide, 1987
paperback edition, page 740:

	The expression E1[E2] is identical (by definition)
	to *((E1)+(E2)).

The October 86 draft of the ANSI C standard said (Rationale
section 3.3.2.1)
	The Committee found no reason to disallow the
	symmetry that permits a[i] to be written as i[a].
and in the standard proper
	The definition ... is that E1[E2] is identical
	to (*(E1+(E2))).
[The two definitions are equivalent.]

What we're getting at here is that if you want to represent
positions in 3D space, a good dodge is to write

#define x_of(V) 0[V]
#define y_of(V) 1[V]
#define z_of(V) 2[V]

Notice that there are no superfluous parentheses, that
this notation can be read directly as "2nd element of V",
and that this has always been explicitly legal in C.

Some versions of the Green Hills C compiler for MC680x0 do not
accept this syntax.  There may be other versions which do accept it.
There may be other compilers with this error:  the VAX-11 C manual
for VMS says "addr[intexp]" which suggests that it MAY have the
same mistake.

BTW: now that the ANSI C committee have decided to flout centuries
of mathematical tradition and make (X+Y) different from X+Y, what
does this do to E1[E2]?  [The two definitions above are NOT
equivalent if parentheses act as in FORTRAN.  This is a good
reason why parentheses should have their usual mathematical
meaning:  straightforward reasoning about a program can go
seriously wrong if parentheses act so strangely.]