Re: 'C' Operators precedence

Matthew Kirkwood (
Wed, 20 May 1998 05:24:16 +0100 (BST)

On Tue, 19 May 1998, Richard B. Johnson wrote:

> There were two others on this thread, but I was interrupted by a
> 'work break' so I hit the 'D' key.
> In the case of:
> a = b + c + f(d);
> ... f(d) must be evaluated first because of the precedence
> of the () operator.

Eh? Precedence is just a parsing issue whose purpose is to save

> It is important to understand what f(d) really means. It
> means to evaluate 'd' using an object called 'f'. F is not
> necessarily a function. It could be a macro.
> The closing of a parenthesis means "evaluate the objects
> between the opening and closing parenthesis". In some texts,
> "()" is called the evaluation operator. Each time an
> evaluation operation is complete, a sequence-point is
> established. This is the only reason why objects are
> evaluated before a function is called. The "()" operator
> forces this.

No, no, no. As it happens, the precedence of function application in c is
not very important, and is only required to distinguish between a+b(c)
being a+(b(c)) or (a+b)(c).

> This is also the reason why calling a function through a
> pointer must use 'extra' parenthesis:
> r = (*f)(a);
> ... since
> (*f) closes the parenthesis
> ... and
> (a) closes the parenthesis
> ... evaluation occurs left-to-right as:
> de-reference pointer 'f', then evaluate 'a' using the
> object addressed by it.

You seem to be confusing parsing and evaluation.

> If we didn't have the extra set of parenthesis as:
> c = *f(a);
> ... we tell the compiler to evaluate 'a' using object 'f'
> which has not been de-referenced yet, which will not work.
> FYI, some compilers allow c = f(a), where 'f' is a pointer.
> This is bogus and helps prevent 'C' writers from learning
> what they are really doing.
> When seeing ONLY:
> a = b + f(c);
> ... the compiler must evaluate 'c', using object 'f', first
> because '()' has the highest precedence of any 'C' operator.

Evaluation and precedence are independant.

> When seeing:
> a = b + c + d;
> ... the compiler may still not legally evaluate the objects
> in any order because of associativity, but many/most do.
> Optimization is not yet part of the 'C' standard. When
> attempting to optimize code, certain standards are broken as
> long as the code is likely to work.

The left associativity of the '+' operator is a parsing thing. It means
that a+b+c gets parsed as (a+b)+c, and no a+(b+c). That is all. '+' is
associative, so we can be pretty sure that these are the same. c makes
no guarantees about evaluation order of associative, symmetric operators;
(a=0)+a+(a=1) could evaluate in any of a number of ways, and leave a equal
to 0 or 1 afterwards.

> Everything makes sense once one understands the '()' operator.

Keep reading, you might ;-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to