Path: utzoo!mnetor!uunet!husc6!think!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Bug in Green Hills compiler
Message-ID: <6897@brl-smoke.ARPA>
Date: 21 Dec 87 13:41:27 GMT
References: <482@cresswell.quintus.UUCP> <6883@brl-smoke.ARPA> <484@cresswell.quintus.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 34
Keywords: i[a] not understood

In article <484@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>Under the new rules, (X+Y) and X+Y are in fact different, that is,
>they BEHAVE differently.

No, they don't, unless the expressions X and Y contain operators that
bind more tightly that + and "X+Y" is imbedded in a context where that
matters.

>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.

Parentheses have the same effect they have always had in C, namely they
can be used to override default operator associativity and precedence.

The only change brought on by the latest X3J11 meeting is that compilers
are no longer free to run rampant when optimizing expressions involving
nominally commutative+associative operators.

>What I was asking for, and still would like, is
>a plain statement of what the new definition of E1[E2] is,

The first one you quoted is probably the best form to use, since E1 may
contain some operator that binds more weakly than +.

>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.

2[a+1] is equivalent to *(2+(a+1)).  Assuming that a through a+3 are all
meaningful addresses, then this is indeed equivalent to a[3].