Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!apollo!wanginst!mckeeman
From: mckeeman@wanginst.EDU (William McKeeman)
Newsgroups: comp.lang.c
Subject: Re: Disregarding parentheses in C
Message-ID: <1038@wanginst.EDU>
Date: Wed, 22-Apr-87 12:02:00 EST
Article-I.D.: wanginst.1038
Posted: Wed Apr 22 12:02:00 1987
Date-Received: Fri, 24-Apr-87 23:53:11 EST
References: <200@m10ux.UUCP> <6378@mimsy.UUCP>
Reply-To: mckeeman@wanginst.UUCP (William McKeeman)
Organization: Wang Institute
Lines: 86
Keywords: C parentheses evaluation order parsing
Summary: x3j11 wording (95 boring lines)

In article <6378@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>According to K&R p. 185,
>
>    Expressions involving a commutative and associative operator
>    ( * , + , & , | , ^ ) may be rearranged arbitrarily, even in
>    the presence of parentheses; to force a particular order of
>    evaluation an explicit temporary must be used.
>
>I have no idea how the corresponding idea is phrased in the dpANS,
>but at least they provided *some* sort of escape (the dreaded unary
>plus).
>-- 

I know some folks are getting tired of all of this.  Maybe some facts would
help cut down on the various opinions in reaction to guesses.

[begin of quote of x3j11 document July 9, 1986, available from Computer and
Business Equipment Manufacturers Association, 311 First Street, N.W., Suite
500, Washington, DC 20001-2178. (202)737-8888]

3.3 EXPRESSIONS

   An _expression_ is a sequence of operators and operands that specifies how
to compute a value, or how to generate side effects, or both.

   Except as indicated by the syntax [see footnote 15] or otherwise specified
later (for the function-call operator (), the unary plus operator, &&, ||,
?:, and comma operators), the order of evaluation of an expression is
unspecified.  The implementation may evaluate subexpressions in any order,
even if the subexpressions produce side effects.  The order in which side
effects take place is unspecified, except that the evaluation of the operands
of an operator that involves a sequence point shall not be interleaved with
other evaluations.

   An expression involving more than one occurrence of the same commutative
and associate binary operator (*, +, &, ^, |) may be regrouped arbitrarily,
even in the presence of parentheses, provided the types of the operands or of
the results are not changed by this regrouping.  To force a particular
grouping of operations, either the value of the expression to be grouped
may be explicitly assigned to an object, or grouping parentheses may be
preceded by a unary plus operator.

... (skipping)

   If an expection occurs during the evaluation of an expression (that is,
if the result is not mathematically defined or not representable), the
behavior is undefined.

3.6 STATEMENTS

... (skipping)

   A _full_expression_ is an expression that is not part of another
expression.  Each of the following is a full expression: an initializer; the
expression in an expression statement; the controlling expression of a
selection statement (if or switch); the controlling expression of an
iteration statement (while, do, or for); the expression in a return
statement.  The end of a full expression is a sequence point.

[end of quote]

Footnote 15 tells how to imply precedence from the syntax and order of
presentation in the draft standard.

[begin of quote of Rationale, dated 7 July 1986, section 2.1.2.3, Program
execution.]

   ... A question sometimes asked regarding optimization is, "Is the
rearrangement still conforming if the pre-computed expression might raise a
signal (such as division by zero)?"  Fortunately for optimizers, the answer
is "Yes", because any evaluation that raises a computational signal has
fallen into an _undefined_behavior_ (refer to section 3.3) for which any
action is allowable.

[end of quote]

[begin comment by McKeeman]

The only constraint on compiler rearrangements is that the TYPE of the
operands and results not thereby be changed.  (emphasis mine)

[end of comment]
-- 
W. M. McKeeman            mckeeman@WangInst
Wang Institute            decvax!wanginst!mckeeman
Tyngsboro MA 01879