Thread: operator assoiciation

why sizeof (int)(*p) is not compilable by gcc?
I thought sizeof, (int) and * has the same order of precedence and the association should be right to left, but
sizeof (int)(*p) is wrong.
I have to use sizeof ((int)(*p)) instead.

Also, sizeof (int) *p is interpreted as (sizeof(int) )* p instead of sizeof ((int)(*p)) as I expected. Any reason?

Thanks for any tips

sizeof x is an operator that produces a numeric value by your precompiler. Ergo, sizeof(int)(*p) is like saying 4(*p). Why is 4(*p) not compileable by gcc?

Incidentally, why would you want to use a cast inside a sizeof operator anyway? Perhaps you want sizeof(int) * sizeof(*p);

Originally Posted by master5001

sizeof x is an operator that produces a numeric value by your precompiler. Ergo, sizeof(int)(*p) is like saying 4(*p). Why is 4(*p) not compileable by gcc?

sizeof is not handled by precompiler and it is an operator with the same order of precedence as (typecast) and * (dereference)

Interesting, though yet despite your knowledge of which processes are pre-compiler duties and which are compiler duties how is it you fail to see the flaw in your own code?

Originally Posted by Salem

Well do you want sizeof(int) or sizeof(*p) ?

Because your first efforts didn't make a lot of sense.

I have programmed C for 5+ years and I do know how to get sizeof(int) and how to get sizeof(*p).
I will never write a code like what I posted.
I am discussing the problem from the "theoretical" POV.

Thanks for any tips

Ok, so I gave my two cents from my decade+ years of programming.

I will never write a code like what I posted.

Then why are you thanking us? Keep up the good work not writing code like that!

Originally Posted by master5001

Ok, so I gave my two cents from my decade+ years of programming.



Then why are you thanking us? Keep up the good work not writing code like that!

Thanks for your help!
But seriously, I still have not got the answer for my questions yet.
I would appreciate any further help.

Seriously the reason is just order of operations. I follow and agree with gcc on this one.

sizeof (int)(*p)

sizeof (int)(*p)
sizeof (int)(*p)

thus

4(*p)

which shouldn't compile.

You are wanting order of operations to look at it like this

sizeof (int)(*p)
sizeof (int)(*p)

But in order to kill that ambiguity, one should use parenthesis. I would surmise this is not consistent behavior and should actually go on the "undefined" list. Since some compilers may not agree with my order of operations nor gcc's.

I think your answer is greedy parsing, sizeof is going to take the next thing it can find that makes sense -- (int) makes sense, because sizeof can take a parenthesized type, but (int)(*p) doesn't. Hence sizeof(int) is parsed.

Originally Posted by master5001

Seriously the reason is just order of operations. I follow and agree with gcc on this one.

sizeof (int)(*p)

sizeof (int)(*p)
sizeof (int)(*p)

thus

4(*p)

which shouldn't compile.

Why sizeof is associated before (int)?
This should be right to left, is it?

Which is why I would contend this is a case that is most likely undefined. But I would need CornedBee's two cents on this one. sizeof is not particularly intelligent as far as what it takes as an argument. It just grabs its nearest neighbor.

Originally Posted by tabstop

I think your answer is greedy parsing, sizeof is going to take the next thing it can find that makes sense -- (int) makes sense, because sizeof can take a parenthesized type, but (int)(*p) doesn't. Hence sizeof(int) is parsed.

Thusly, parentheses in your example is required so that sizeof returns the size of the result of the correct expression.

Originally Posted by master5001

sizeof is not particularly intelligent as far as what it takes as an argument. It just grabs its nearest neighbor.

This makes sense to me: though it is defined as the same order of precedence as (int) and * but not implemented in that way in GNU. How about other C compiler, like intel's one?