Precedence of sizeof

[Frederick Gotham]

sizeof has the same precedence as a cast, and they both bind from right to
left. The following won't compile for me with gcc:

int main(void)
{
sizeof(double)5;

return 0;
}

Has it got something to do with "globbing"?

 

[Cong Wang]

sizeof has the same precedence as a cast, and they both bind from right to
left. The following won't compile for me with gcc:

int main(void)
{
sizeof(double)5;

return 0;
}

Has it got something to do with "globbing"?

"sizeof ((double)5)" works well.

 

[yuhaikuo]

"sizeof ((double)5)" works well.

 

[Antti-Juhani Kaijanaho]

sizeof has the same precedence as a cast

No it doesn't.

Has it got something to do with "globbing"?

Unlikely.

 

[Frederick Gotham]

Cong Wang posted:

"sizeof ((double)5)" works well.

Yes, I realise that. My question pertains to operator precedence and
associativity -- specifically, why:

sizeof(double)5

is interpretted by gcc as:

(sizeof(double))5

rather than:

sizeof((double)5)

 

[Richard Tobin]

sizeof has the same precedence as a cast

The standard does not describe C's syntax in terms of operator
precedence; that's just a handy way of summarizing some common cases.

The relevant part of the grammar is:

unary-expression:
[...]
unary-operator cast expression
sizeof unary-expression
sizeof ( type-name )

cast-expression:
unary-expression
( type-name ) cast expression

So in:

sizeof(double)5;

"(double)5" is not a unary expression, so only "sizeof ( type-name )"
is possible, and that of course doesn't work because of the "5"
afterwards.

-- Richard

 

[lovecreatesbea...]

sizeof has the same precedence as a cast, and they both bind from right to
left. The following won't compile for me with gcc:

int main(void)
{
sizeof(double)5;

return 0;
}

The code: sizeof(double)5; in the example mean: sizeof(double) [X] 5;,
in the example the sequence [X] is none. It is trying to connect two
numeric expressions without operators. This is not correct. You may
mean some similar code like the following.

int main(void){
/*sizeof(double)5;*/
sizeof(double) * 5;
sizeof((double)5);

return 0;
}

 

[Robert Gamble]

sizeof has the same precedence as a cast

No, the sizeof operator has a higher precedence than the cast operator.

and they both bind from right to
left. The following won't compile for me with gcc:

int main(void)
{
sizeof(double)5;

return 0;
}

As it shouldn't because it doesn't make any sense.

Has it got something to do with "globbing"?

I have no idea what you mean by "globbing" in this context, your
expression is evaluated as:
(sizeof(double)) 5;
which is a syntax error and is why it doesn't compile.

Robert Gamble

 

[Frederick Gotham]

Antti-Juhani Kaijanaho posted:

No it doesn't.

Please indicate where you obtain that information, because my own operator
table indicates that they indeed have equal precedence.

 

[Frederick Gotham]

Richard Tobin posted:

unary-expression:
[...]
unary-operator cast expression
sizeof unary-expression
sizeof ( type-name )

cast-expression:
unary-expression
( type-name ) cast expression

So in:

sizeof(double)5;

"(double)5" is not a unary expression, so only "sizeof ( type-name )"
is possible, and that of course doesn't work because of the "5"
afterwards.

So is a unary expression something simple like a literal or the name of an
object? Does that mean that the following should be bogus:

int main(void)
{
sizeof(5+4);
return 0;
}

It compiles just fine with gcc.

 

[Frederick Gotham]

(e-mail address removed) posted:

The code: sizeof(double)5; in the example mean: sizeof(double) [X] 5;,
in the example the sequence [X] is none. It is trying to connect two
numeric expressions without operators. This is not correct. You may
mean some similar code like the following.

int main(void){
/*sizeof(double)5;*/
sizeof(double) * 5;
sizeof((double)5);

return 0;
}

No. As I've already mentioned, this entire thread is to do with operator
precedence and associativity.

 

[lovecreatesbea...]

Cong Wang posted:

associativity -- specifically, why:

sizeof(double)5

is interpretted by gcc as:

(sizeof(double))5

rather than:

sizeof((double)5)

The operand '5' has no operators on both of its left and right sides. I
think the associativity does not apply here.

 

[Frederick Gotham]

Robert Gamble posted:

No, the sizeof operator has a higher precedence than the cast operator.


As it shouldn't because it doesn't make any sense.

It makes perfect sense. The literal, 5, is cast to a double, and the result
is supplied as an operand to sizeof.

Your expression is evaluated as: (sizeof(double)) 5; which is a syntax
error and is why it doesn't compile.

I know that. My question is why it isn't interpreted as:

sizeof((double)5)

My operator precedence table would have me to believe that it should.

 

[Frederick Gotham]

(e-mail address removed) posted:

The operand '5' has no operators on both of its left and right sides.

5 is the operand of the cast.

The result of the cast is the operand of sizeof.

 

[xdevel]

Robert Gamble ha scritto:

No, the sizeof operator has a higher precedence than the cast operator.

No, sizeof and cast have the same precedence in fact they are on
the same row:
! ~ ++ -- + - * & (type) sizeof
but they bind from right to left

 

[lovecreatesbea...]

(e-mail address removed) posted:



The result of the cast is the operand of sizeof.

I meant the '5' in your original example: sizeof(double)5;

 

[Fred Kleinschmidt]

sizeof has the same precedence as a cast, and they both bind from right to
left. The following won't compile for me with gcc:

int main(void)
{
sizeof(double)5;

return 0;
}

Has it got something to do with "globbing"?

Consider this:
sizeof(double)-5

There is a syntactic ambiguity in this type of expression. It could be
interpreted as three unary operators: negation, the cast (double)
and 'sizeof', successively applied to the value 5:
sizeof( (double)(-5) )
or it could be interpreted as a binaary subtraction whose
operands are sizeof(double) and 5:
(sizeof (double)) - 5

This ambiguous case is resolved quite arbitrarily by declaring that the
latter interpretation shall be used.

Now replace the minus with a plus:
sizeof(double)+5
By the same logic, this is interpreted as (sizeof(double)) + 5

The same logic is used to have
sizeof(double)5 interpreted as (sizeof(double))5
which is a syntax error.

This type of thing is why many people like to
include parentheses around the operand of sizeof regardless of
whether that operand is a type name or a data object. It makes it
clear what the intent of the expression really is.

 

[Chris Dollin]

(e-mail address removed) posted:



5 is the operand of the cast.

The result of the cast is the operand of sizeof.

Since the text doesn't parse, you can't say "5 is the operand of the cast"
or "The result of the cast is the operand of sizeof" and be talking
about C grammar.

 

[Richard Tobin]

So is a unary expression something simple like a literal or the name of an
object?

I'm sure you can read the grammar as well as I can. But essentially:

A unary-expression is a postfix-expression optionally preceded by
++, --, &, *, +, =, ~, !, or sizeof, or is sizeof ( type-name ).

A postfix-expression is a primary-expression optionally followed by
a subscript, and argument list, ., ->, ++, or --.

A primary-expression is an identifier, a constant, a string-literal,
or a parenthesized expression.

Does that mean that the following should be bogus:

sizeof(5+4);

No, (5+4) is a primary-expression which is a postfix-expression which is
a unary-expression.

-- Richard

 

[Rod Pemberton]

Robert Gamble posted:



It makes perfect sense. The literal, 5, is cast to a double, and the result
is supplied as an operand to sizeof.




I know that. My question is why it isn't interpreted as:

sizeof((double)5)

My operator precedence table would have me to believe that it should.

I'm not sure how they calculate the precedence level from the grammar, but
"C: A Reference Manual" by Samuel Harbison and Guy Steele, Jr. 3rd. edition,
page 167, lists 17 precedence levels. They list unary operators:
sizeof,~,!,-,+,&,* as level 15 and unary casts as level 14 (i.e., cast has
lower precedence). Both are right associative. I know they corrected at
least one error in table at a later date. Whose precedence table are you
using?


Rod Pemberton