Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Bug in Green Hills compiler
Message-ID: <484@cresswell.quintus.UUCP>
Date: 21 Dec 87 05:42:10 GMT
References: <482@cresswell.quintus.UUCP> <6883@brl-smoke.ARPA>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 24
Keywords: i[a] not understood
Summary: it's not me that's misunderstanding

In article <6883@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <482@cresswell.quintus.UUCP> [I wrote]:
> >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]?
> 
> First of all, you appear to be under some misunderstanding.
> (X+Y) is no more different from X+Y under the new rule than it ever was.

Under the new rules, (X+Y) and X+Y are in fact different, that is,
they BEHAVE differently.  (X and Y stand for arbitrary expressions.)
The point here is that E1[E2] has in the past been defined in one of
two previously equivalent ways:
	(*((E1)+(E2)))
or	(*(E1+(E2)))
If parentheses have an operational effect, these two definitions are
no longer equivalent.  What I was asking for, and still would like, is
a plain statement of what the new definition of E1[E2] is, and in
particular, a plain statement of under which conditions the compiler
is entitled to merge E1 and E2 rather than evaluating them separately.
(Note that this is POINTER arithmetic, >>not<< integer arithmetic, so
statements about equivalence if integer overflow is disabled are not
enough to tell me whether the compiler is entitled to treat
2[a+1] as a[3] or not.)  Surely this isn't too much to ask?