sizeof: Why parentheses needed when used with data types (when not required with variables)

[krishna]

Doesn't the context provide enough information (to the compiler) when
it sees "sizeof int" and interpret it the same way as "sizeof x"?

-Krishna.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Seungbeom Kim]

krishna wrote:
> Doesn't the context provide enough information (to the compiler) when
> it sees "sizeof int" and interpret it the same way as "sizeof x"?

I'm not a compiler expert, but I could think of some tricky cases.
Consider the compiler saw a stream of tokens:

sizeof int * * E

It could be sizeof(int *) * E, or sizeof(int) * (* E). (Of course,
E of an arithmetic type would make only the former case well-formed,
and E of a pointer type would make only the latter well-formed, and
these two cannot happen at the same time.)

On the other hand, I don't understand why the Standard allows "sizeof x"
without parentheses. It's much clearer with mandatory parentheses.
(I have to admit that I often write "fgets(buf, sizeof buf, stdin)" :D)

--
Seungbeom Kim

[tohava]

On Nov 10, 10:26 am, Seungbeom Kim <musip...@bawi.org> wrote:
> Consider the compiler saw a stream of tokens:
>
> sizeof int * * E
>
> It could be sizeof(int *) * E, or sizeof(int) * (* E). (Of course,
> E of an arithmetic type would make only the former case well-formed,
> and E of a pointer type would make only the latter well-formed, and
> these two cannot happen at the same time.)

I do not believe this is a problem, since barring the lack of sequence
points, a compiler can interpret a +++ b (I forgot whether it's a + (+
+b) or (a++) + b, but you get the point).

--

[Seungbeom Kim]

tohava wrote:
> On Nov 10, 10:26 am, Seungbeom Kim <musip...@bawi.org> wrote:
>> Consider the compiler saw a stream of tokens:
>>
>> sizeof int * * E
>>
>> It could be sizeof(int *) * E, or sizeof(int) * (* E). (Of course,
>> E of an arithmetic type would make only the former case well-formed,
>> and E of a pointer type would make only the latter well-formed, and
>> these two cannot happen at the same time.)
>
> I do not believe this is a problem, since barring the lack of sequence
> points, a compiler can interpret a +++ b (I forgot whether it's a + (+
> +b) or (a++) + b, but you get the point).

That's the "maximal munch rule" for determining tokens; since "++" is
a valid token when "+++ b" is in the input stream, "++" is considered
the next token, and the expression is parsed as (a ++) + b. It's not
the same problem as the OP's, though, because the latter is not about
tokens (lexical analysis) but about parsing (syntax analysis).

Of course, a rule that resolves the ambiguity in the OP's case /could/
have been made (though the maximal munch rule would be too rudimentary
here). Just as 2+3*4 is parsed as 2+(3*4) when it could have been parsed
differently. Or just as sizeof a*b is parsed as (sizeof a)*b instead of
sizeof(a*b). For some reason, the ambiguity has almost been precluded
by requiring parentheses for sizeof(type-id), instead of not requiring
parentheses and resolving ambiguities in other ways.

My point is that an ambiguity is possible without requiring parentheses,
and that even though it could have been resolved by another arbitrary
rule, it's much clearer when parentheses are required. sizeof expression
is rather an exceptional case that doesn't require parentheses, and I
would make them required as well if I designed the language.

--
Seungbeom Kim