«

Richard G. Riley said:

> On 2006-03-14, Robert Gamble <> wrote:
>>
>> Did you even read the section you posted?
>
> <sarcasm on> No. I posted it totally blindly just guessing it had
> something to do with the OP. I guess I was luck I hit on something to
> do with sizeof eh? <sarcasm off>

I see very little sarcasm there.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On 2006-03-14, Richard Heathfield <> wrote:
> Richard G. Riley said:
>
>> "sizeof" operator does not evaluate the expression contained therein
>> it seems.
>
> Correct.
>
>> I didnt know that :
>
> Evidently.
>
>> but purely because I never stuck an
>> expression in it for reasons unknown - I just assumed it as a
>> "preprocessor" type thing and just never did it.
>
> It is nothing to do with the preprocessor.
>
>
>> I can claim no genius.
>
> Evidently.
>
>>
>> It would be the same had you put
>>
>> sizeof(x=3);
>
> Correct.
>
>>
>> I would agree that it is a little confusing
>
> I wouldn't.
>
>> since the
>> compiler (gcc) happily lets you write something like
>>
>> sizeof(x=funcCall(y)) too!
>
> It's supposed to.
>
>>
>> Looking at this in n1124pdf:
>>
>> 6.5.3.4 The sizeof operator
>> Constraints
>>
>> 2 The sizeof operator yields the size (in bytes) of its operand, which
>> may be an expression or the parenthesized name of a type. The size is
>> determined from the type of the operand. The result is an integer. If
>> the type of the operand is a variable length array type, the operand
>> is evaluated; otherwise, the operand is not evaluated and the result
>> is ....

Out of curiosity, is

sizeof cos() [no prototype in scope] allowed [sizeof(int)], or is it still
undefined behavior?

That is, is it the evaluation of a function that the compiler has
"wrong" what causes undefined behavior, or is it the presence in the
source of the call itself?

how about

sizeof(((int(*)())0)())?

Jordan Abel <> writes:

> On 2006-03-14, Richard Heathfield <> wrote:
> Out of curiosity, is
>
> sizeof cos() [no prototype in scope] allowed [sizeof(int)], or is it still
> undefined behavior?

Well, implicit declarations were removed in C99, so it's a constraint
violation.

I was going to say "it's fine" for C90, but I gave it a little more
thought after your next sentence. Because, whether or not it is
actually evaluated, it results in the implicit declaration.

> That is, is it the evaluation of a function that the compiler has
> "wrong" what causes undefined behavior, or is it the presence in the
> source of the call itself?

It is the declaration of cos() that causes undefined behavior. cos is
a reserved identifier (7.1.3#1), and is only allowed to refer to the
standard library function. Since your cos does not, it violates
this rule. Rules 6.2.2#2 and 6.2.7#2 apply when it's a function you've
defined yourself. These are C99 references, but they appear
equivalently in C90.

However, in C90, sizeof(foo()) would be allowed (if you never define
foo()). The implicit declaration is fine, because C90 3.7
(corresponding to C99 6.9) only requires a definition to exist if you
use its identifier in an expression other than the operand of a sizeof.

> how about
>
> sizeof(((int(*)())0)())?

Perfectly fine. The expression is never evaluated.