472,993 Members | 2,555 Online

# Regarding sizeof Operator

#include<stdio.h>
main()
{
int x=10,y;
y=sizeof(++x);

printf("x=%d\ny=%d\n",x,y);
}

Oput Put

x=10
y=4

why not x=11

Mar 14 '06 #1
12 2353
sonu said:
#include<stdio.h>
main()
{
int x=10,y;
y=sizeof(++x);

printf("x=%d\ny=%d\n",x,y);
}

Oput Put

x=10
y=4

why not x=11

Because sizeof does not evaluate its operand.

--
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)
Mar 14 '06 #2
On Tuesday 14 March 2006 07:10, sonu opined (in
#include<stdio.h>
main()
{
int x=10,y;
y=sizeof(++x);

printf("x=%d\ny=%d\n",x,y);
}

Oput Put

x=10
y=4

why not x=11

Do not post the same question every 6 minutes, especially not with the
different subject line (it makes it difficult to ignore). It is only
reasonable to assume your post is not seen after at least 24 hours.
This is not a chat room, this is Usenet. Look up what it is and it's
history. GIYF.

In any case, you did get two replies very quickly.

--

Latin is a language,
First it killed the Romans,
And now it's killing me.

Mar 14 '06 #3
On 2006-03-14, sonu <sa****************@gmail.com> wrote:
#include<stdio.h>
main()
{
int x=10,y;
y=sizeof(++x);

printf("x=%d\ny=%d\n",x,y);
}

Oput Put

x=10
y=4

why not x=11

"sizeof" operator does not evaluate the expression contained therein
it seems. I didnt know that : 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. I can claim no genius.

It would be the same had you put

sizeof(x=3);

I would agree that it is a little confusing since the
compiler (gcc) happily lets you write something like

sizeof(x=funcCall(y)) too!

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 ....

There is a rather unhelpful footnote which states

"the operand of a sizeof operator is usually not evaluated"

Hopefully someone will enlighten us both as to what the standard means
: I just assumed it was a pre-processor type thing and would never
have thought the compiler would allow such a statement there.
Mar 14 '06 #4
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 ....

There is a rather unhelpful footnote which states

"the operand of a sizeof operator is usually not evaluated"
That is merely an expansion of the normative text. It adds no particular
value.
Hopefully someone will enlighten us both as to what the standard means
: I just assumed it was a pre-processor type thing
sizeof is a C keyword, not a preprocessor directive.
and would never
have thought the compiler would allow such a statement there.

Evidently. And yet it does, because it must.

What you think does not necessarily equate to what is true.

--
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)
Mar 14 '06 #5
Richard Heathfield wrote:
Richard G. Riley said:

<snip>
There is a rather unhelpful footnote which states

"the operand of a sizeof operator is usually not evaluated"

That is merely an expansion of the normative text. It adds no
particular value.

Although sizeof must evaluate the size of a variable length array under c99
rules ... maybe it's a vague reference to that - I believe it's the only
case in which sizeof /evaluates/?

<snip>
--
==============
Not a pedant
==============
Mar 14 '06 #6
On 2006-03-14, pemo <us***********@gmail.com> wrote:
Richard Heathfield wrote:
Richard G. Riley said:

<snip>
There is a rather unhelpful footnote which states

"the operand of a sizeof operator is usually not evaluated"

That is merely an expansion of the normative text. It adds no
particular value.

Although sizeof must evaluate the size of a variable length array under c99
rules ... maybe it's a vague reference to that - I believe it's the only
case in which sizeof /evaluates/?

<snip>

I just found the relevant part in K&R2 A7.4.8 : it states that expressions
are not evaluated. While I did download n1124.pdf, I always find it
hard to find something there and all I did find I documented in
that post. I'm sure KT or somewould more aufait with the document can
quote the relevant part.
--
Debuggers : you know it makes sense.
http://heather.cs.ucdavis.edu/~matlo...g.html#tth_sEc
Mar 14 '06 #7
Richard G. Riley wrote:
On 2006-03-14, pemo <us***********@gmail.com> wrote:
Richard Heathfield wrote:
Richard G. Riley said:
<snip>
There is a rather unhelpful footnote which states

"the operand of a sizeof operator is usually not evaluated"

That is merely an expansion of the normative text. It adds no
particular value.

Although sizeof must evaluate the size of a variable length array under c99
rules ... maybe it's a vague reference to that - I believe it's the only
case in which sizeof /evaluates/?

<snip>

I just found the relevant part in K&R2 A7.4.8 : it states that expressions
are not evaluated.

They weren't when K&R2 was published. K&R2 doesn't cover C99.
hard to find something there and all I did find I documented in
that post. I'm sure KT or somewould more aufait with the document can
quote the relevant part.

(It's "au fait" by the way, two words)

Did you even read the section you posted?

"If the type of the operand is a variable length array type, the
operand
is evaluated; otherwise, the operand is not evaluated ..."

Robert Gamble

Mar 14 '06 #8
On 2006-03-14, Robert Gamble <rg*******@gmail.com> wrote:
Richard G. Riley wrote:
On 2006-03-14, pemo <us***********@gmail.com> wrote:
> Richard Heathfield wrote:
>> Richard G. Riley said:
>>
>
>
><snip>
>
>>> There is a rather unhelpful footnote which states
>>>
>>> "the operand of a sizeof operator is usually not evaluated"
>>
>> That is merely an expansion of the normative text. It adds no
>> particular value.
>
> Although sizeof must evaluate the size of a variable length array under c99
> rules ... maybe it's a vague reference to that - I believe it's the only
> case in which sizeof /evaluates/?
>
><snip>
>
>
I just found the relevant part in K&R2 A7.4.8 : it states that expressions
are not evaluated.

They weren't when K&R2 was published. K&R2 doesn't cover C99.
hard to find something there and all I did find I documented in
that post. I'm sure KT or somewould more aufait with the document can
quote the relevant part.

(It's "au fait" by the way, two words)

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>

"If the type of the operand is a variable length array type, the
operand
is evaluated; otherwise, the operand is not evaluated ..."

The footnote I also cited?

"the operand of a sizeof operator is usually not evaluated"

As I said, I'm not so au fait with this stuff and sometimes have
difficulty translating it too, and the word "usually" left some doubt
in my mind.

I did state that I wasnt sure? Didnt I?

But thanks for the clarification anyway.

Robert Gamble

Mar 14 '06 #9
pemo said:
Richard Heathfield wrote:
Richard G. Riley said:

<snip>
There is a rather unhelpful footnote which states

"the operand of a sizeof operator is usually not evaluated"

That is merely an expansion of the normative text. It adds no
particular value.

Although sizeof must evaluate the size of a variable length array under
c99 rules ...

Yes, and the normative text explains that perfectly clearly.

--
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)
Mar 14 '06 #10
Richard G. Riley said:
On 2006-03-14, Robert Gamble <rg*******@gmail.com> 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)
Mar 14 '06 #11
On 2006-03-14, Richard Heathfield <in*****@invalid.invalid> 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?

sizeof(((int(*)())0)())?
Mar 14 '06 #12
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-14, Richard Heathfield <in*****@invalid.invalid> 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.

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

Perfectly fine. The expression is never evaluated.
Mar 14 '06 #13

This thread has been closed and replies have been disabled. Please start a new discussion.