is *ptr++ equivalent to *(ptr++)

[Lawrence Kirby]

Furthermore, the table is wrong (at least if it's the same table as the
one I'm used to). The expression

sizeof (int) - 1

is parsed as

(sizeof (int)) - 1

not as

sizeof ((int) (- 1))

as the table implies.

The problem here is not that the precedence table mispredicts the binding,
it is that it cannot predict it at all, the precedence rules allow both of
these. A precedence table assumes that you already know what operators are
being used or have a grammar without such ambiguities, and it will then
determine how operands are bound to those operators. In this case there is
an ambiguity over which operators the original exprrssion contains. In the
first parse there is a sizeof operator and a binary -, in the second parse
there is a sizeof, a cast and a unary -. This ambiguity cannot be solved
by pure precedence, there have to be other non-precedence based rules to
resolve this. E.g. a rule that states that sizeof followed by a type in
parentheses is parsed as a single sizeof(TYPE) operation rather than
sizeof (CAST). I don't have K&R2 with me here, but I though it did mention
sizeof in the accompanying text for the precedence table.

This demonstrates that the grammar form used to specify C's syntax is more
powerful than precedence rules since it can express this directly.

Lawrence

 

[Lawrence Kirby]

Not so. * and ++ have the same precedence, so the word is not useful in this
context.

In the precedence tables given in K&R and K&R 2 that is true but other
equivalent precedence tables are possible. IIRC King uses a precedence
table where postfix operators have higher precedence than prefix operators.

As long as the table predicts that when an operand is between two unary
operators it is bound to the one on its right that's fine.

Lawrence

 

[Chris Croughton]

The problem here is not that the precedence table mispredicts the binding,
it is that it cannot predict it at all, the precedence rules allow both of
these. A precedence table assumes that you already know what operators are
being used or have a grammar without such ambiguities, and it will then
determine how operands are bound to those operators. In this case there is
an ambiguity over which operators the original exprrssion contains. In the
first parse there is a sizeof operator and a binary -, in the second parse
there is a sizeof, a cast and a unary -. This ambiguity cannot be solved
by pure precedence, there have to be other non-precedence based rules to
resolve this. E.g. a rule that states that sizeof followed by a type in
parentheses is parsed as a single sizeof(TYPE) operation rather than
sizeof (CAST). I don't have K&R2 with me here, but I though it did mention
sizeof in the accompanying text for the precedence table.

Thanks for that explanation. In my precedence-based parser I simply
remembered whether the previous token was an identifier or an operator,
if it was an identifier I treated it like a function call (with
sizeof(...) being handled as a "compile-time function") which got the
precedence right. However, the ternary operator can't be done that
simply using a precedence-based parser.

This demonstrates that the grammar form used to specify C's syntax is more
powerful than precedence rules since it can express this directly.

Indeed. With a precedence-only grammar you can't distinguish between
unary and binary operators which use the same token without remembering
the context. (Of course you can't with BNF either, the 'state' or
context is in remembering which rule you're processing, but it's easier
to describe in BNF.)

Chris C

 

[Tim Rentsch]

The problem here is not that the precedence table mispredicts the binding,
it is that it cannot predict it at all, the precedence rules allow both of
these. A precedence table assumes that you already know what operators are
being used or have a grammar without such ambiguities, and it will then
determine how operands are bound to those operators. In this case there is
an ambiguity over which operators the original exprrssion contains. In the
first parse there is a sizeof operator and a binary -, in the second parse
there is a sizeof, a cast and a unary -. This ambiguity cannot be solved
by pure precedence, there have to be other non-precedence based rules to
resolve this. E.g. a rule that states that sizeof followed by a type in
parentheses is parsed as a single sizeof(TYPE) operation rather than
sizeof (CAST).

This demonstrates that the grammar form used to specify C's syntax is more
powerful than precedence rules since it can express this directly.

The table isn't supposed to be a table of operator precedences for an
operator precedence grammar. If it were, there are already problems
without casts, because + and - appear in two different places as
different operators.

If we take the table to be what it pretty clearly was meant to be,
which is a compact summary intended for human consumption, then adding
a level below sizeof/++ that has just casts in it (or, adding a level
for sizeof(type) just above), does a reasonable job of specifying
precedences for its intended audience.

It isn't that the comments about operator precedence are wrong; only
that they seem to be applying a technical standard in what is pretty
clearly a non-technical arena.

None of which changes my basic point, which is that the table can't be
relied on for defining "precedence" in a technically accurate way.

I don't have K&R2 with me here, but I though it did mention
sizeof in the accompanying text for the precedence table.

I didn't say the book is wrong. I said the table is wrong.

 

[Dave Thompson]

On Tue, 19 Jul 2005 23:19:15 +0000 (UTC), Richard Heathfield

That isn't particularly helpful. Of rather more explanatory power is the
table on p53 of K&R, which shows us that * and ++ have the same precedence
level, so the ordering within the statement becomes relevant - and that
ordering is right-to-left for that particular precedence level.

I concur with the other posters; what we informally call precedence is
a shorthand for the decisions made by the grammar rules, and by those
rules postfix are higher than prefix with a variation for sizeof.

Associativity is also implied by the grammar rules and is actually
defined in mathematics only for binary operators/ions, but the
situation for postfix versus prefix can be seen as similar in that the
operand 'prefers' the righthand=postfix operator over the
lefthand=prefix one.

But that still doesn't give a 'right-to-left' rule. That would say
given: double (*funcs[10]) (double) = {sin, cos, etc.}
then: funcs(3.0) would call the function with the value 3.0,
and use its return to subscript funcs. That makes no sense.

The most you can say is: (unless overridden by grouping parentheses)
apply (or bind to) all/any postfix operators first, then all/any
prefix operators. That sure sounds like higher precedence to me.
- David.Thompson1 at worldnet.att.net

 

[siliconwafer]

Yes you are right.

When executed with ANSI C and gcc,* wins over ++.Then what exactly
happens?
another anamoly:
int i = 1;
c = i++ + i++;
is c = 6 or 2?
-Siliconwafer

 

[Suman]

When executed with ANSI C and gcc,* wins over ++.Then what exactly
happens?
another anamoly:
int i = 1;
c = i++ + i++;
is c = 6 or 2?

Are you *really*, *really*, asking this? Better, take a break,
and maybe goto:
http://www.eskimo.com/~scs/C-faq/q3.2.html

 

[Chris Dollin]

When executed with ANSI C and gcc,* wins over ++.Then what exactly
happens?
another anamoly:
int i = 1;
c = i++ + i++;
is c = 6 or 2?

No.

See the FAQ.