a[++j]=a[j]+a[j+1];

[RSoIsCaIrLiIoA]

what is supposed to do

int pto(void)
{int a[50]={0};

a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}

what will be the return value?
thank U

 

[void * clvrmnky()]

what is supposed to do

int pto(void)
{int a[50]={0};

a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}

what will be the return value?
thank U

An integer

I'll share my answer if you share yours.

 

[Xicheng Jia]

what is supposed to do

int pto(void)
{int a[50]={0};

a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}
what will be the return value?

undefined, see a similar example:
http://www.eskimo.com/~scs/c-faq.com/expr/evalorder1.html

Xicheng

 

[Abdo Haji-Ali]

what is supposed to do

int pto(void)
{int a[50]={0};

a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}

what will be the return value?

This might be a useful link for you:
http://groups.google.com/group/micr...all+evaluation+order"&rnum=1#f3c4d4d9039ea004

Abdo Haji-Ali
Programmer
In|Framez

 

[Default User]

what is supposed to do

[snip]

I'll share my answer if you share yours.

RSoIsCaIrLiIoA is a troll on this newsgroup. Please ignore all posts
from him, they are designed to cause trouble.


Brian

 

[Default User]

RSoIsCaIrLiIoA wrote:

undefined, see a similar example:

RSoIsCaIrLiIoA is a troll on this newsgroup. Please ignore all posts
from him, they are designed to cause trouble.


Brian

 

[Default User]

RSoIsCaIrLiIoA wrote:

This might be a useful link for you:

RSoIsCaIrLiIoA is a troll on this newsgroup. Please ignore all posts
from him, they are designed to cause trouble.


Brian

 

[Keith Thompson]

what is supposed to do

int pto(void)
{int a[50]={0};

a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}

what will be the return value?

This might be a useful link for you:
http://groups.google.com/group/micr...all+evaluation+order"&rnum=1#f3c4d4d9039ea004

Not particularly. The referenced article shows some x86 assembly
code. The C code above invokes undefined behavior. (And yes,
RSoIsCaIrLiIoA is a troll.)

 

[chjiangwh]

what is supposed to do
int pto(void)
{int a[50]={0};
a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}
what will be the return value?
thank U

I think the answer is 1.
Equation "a[++j]=a[j]+a[j+1]" :the sequence is right-to left,so it
becomes a[1] = a[0 ]+a[1],at last the function returns a[0],that's 0.
I hope I explained it correctly.
Thx.

 

[Keith Thompson]

what is supposed to do
int pto(void)
{int a[50]={0};
a[0]=1; a[1]=2; a[2]=3; a[3]=4;
j=0;
a[++j]=a[j]+a[j+1];
return a[j-1];
}
what will be the return value?
thank U

I think the answer is 1.
Equation "a[++j]=a[j]+a[j+1]" :the sequence is right-to left,so it
becomes a[1] = a[0 ]+a[1],at last the function returns a[0],that's 0.
I hope I explained it correctly.

No, you didn't. The order of evaluation is not specified except in a
few cases, and this particular expression invokes undefined behavior.

C99 6.5p2 says:

Between the previous and next sequence point an object shall have
its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be read only to
determine the value to be stored.

There are no sequence points within the expression. The value of j is
modified and read for purposes other than determining the value to be
stored in j. A simpler example is
i = i++;
which also invokes undefined behavior.

 

[ais523]

"Abdo Haji-Ali" <[email protected]> writes:

Not particularly. The referenced article shows some x86 assembly
code. The C code above invokes undefined behavior. (And yes,
RSoIsCaIrLiIoA is a troll.)

The referenced thread is a discussion of undefined behaviour in C++,
and how a particular compiler reacts. Many of the points made were also
valid in C (although not all). It is interesting to see how the
behaviour of a particular compiler when given an undefined expression
was affected by what other statements were in the program and whether
it was in debug or release mode.

 

[Naresh]

There are no sequence points within the expression. The value of j is
modified and read for purposes other than determining the value to be
stored in j. A simpler example is
i = i++;
which also invokes undefined behavior.

#include<stdio.h>

void main(void)
{
int k = 0;

k = k++;

printf("\n %d", k);
}

It gives me expected outcome as 1 on msvc 6 without any warnings or
errors. Then, why should we call it as undefined behaviour.Isnt it ok
to consider it as two statements as

k = k + 1;
k = k;

It simply looks like Ra (register) = Ra + 1 and then Ra = Ra.

Regds,
Naresh

 

[Abdo Haji-Ali]

It gives me expected outcome as 1 on msvc 6 without any warnings or
errors. Then, why should we call it as undefined behaviour.Isnt it ok
to consider it as two statements as

k = k + 1;
k = k;

It simply looks like Ra (register) = Ra + 1 and then Ra = Ra.

Well, because it's not that simple, the statement a[++i] = a +
a[i+1]; could be interpreted by the compiler as:

Increment i
evaluate a[i+1] in a
set a

or
evaluate a[i+1] in a
Increment i
set a

Please read the link I provided above for a complete *relevant*
discussion..

Abdo Haji-Ali
Programmer
In|Framez

 

[Naresh]

It gives me expected outcome as 1 on msvc 6 without any warnings or
errors. Then, why should we call it as undefined behaviour.Isnt it ok
to consider it as two statements as

k = k + 1;
k = k;

It simply looks like Ra (register) = Ra + 1 and then Ra = Ra.

Well, because it's not that simple, the statement a[++i] = a +
a[i+1]; could be interpreted by the compiler as:

Increment i
evaluate a[i+1] in a
set a

or
evaluate a[i+1] in a
Increment i
set a

I'm simply not interested in the above examle in which it seems that
there are three additions and two assignments are going on
simultaneously. It would be ok for me to understand it from the basics.
I got down the asm code also.

7:
8: int k = 0;
00401028 mov dword ptr [ebp-4],0
9:
10: k = k++;
0040102F mov eax,dword ptr [ebp-4] ; k is loaded
00401032 mov dword ptr [ebp-4],eax ; k is stored so that k =
k
00401035 mov ecx,dword ptr [ebp-4] ; k is loaded
00401038 add ecx,1 ; k is incremented
by 1
0040103B mov dword ptr [ebp-4],ecx ; incremented k is stored.
11:
12: printf("\n %d", k);
0040103E mov edx,dword ptr [ebp-4]
00401041 push edx
00401042 push offset string "\n %d" (0042001c)
00401047 call printf (004010b0)
0040104C add esp,8

Yes, its a kind of vague that assignment is happening before increment.
so its
k = k;
k = k + 1;

which is okk.. i think i did mistake earlier by saying
k = k+ 1;
k = k;
since k++; means first assigment then increment.

u can see this code now...

00401026 rep stos dword ptr [edi]
7:
8: int k = 0;
00401028 mov dword ptr [ebp-4],0
9:
10: k = ++k;
0040102F mov eax,dword ptr [ebp-4] ; k is loaded
00401032 add eax,1 ; k is incremented
00401035 mov dword ptr [ebp-4],eax ; k is stored
00401038 mov ecx,dword ptr [ebp-4] ; k is loaded
0040103B mov dword ptr [ebp-4],ecx ; k is stored
11:


It confirms my above opinion.
Plz guide if i'm wrong.

Please read the link I provided above for a complete *relevant*
discussion..

I'm really too lazy to go thro the whole 37 comments. I tried but they
lost me somewhere 20 -21.

Regards,
Naresh

 

[Flash Gordon]

#include<stdio.h>

void main(void)
{
int k = 0;

k = k++;

printf("\n %d", k);
}

It gives me expected outcome as 1 on msvc 6 without any warnings or
errors. Then, why should we call it as undefined behaviour.

We call it undefined behaviour because the C programming language does
not define what will happen. See
http://clc-wiki.net/wiki/Undefined_behaviour which even covers your
specific example.

>Isnt it ok
to consider it as two statements as

k = k + 1;
k = k;

It simply looks like Ra (register) = Ra + 1 and then Ra = Ra.

The compiler can do that, or can can treat it as an instruction to
launch a nuclear strike against darkest Peru, which might upset a
certain bear.

Note that with undefined behaviour compilers are allowed to treat it in
the way you happen to expect it, but it might do something different
later, or if you change compiler options, or if you make a seemingly
unrelated change, or if you upgrade the compiler, or if you are trying
to demonstrate it to your boss.

Please don't quote peoples sigs (i.e. the bit above which you quoted)
unless you are commenting on them.

 

[Abdo Haji-Ali]

7:

8: int k = 0;
00401028 mov dword ptr [ebp-4],0
9:
10: k = k++;
0040102F mov eax,dword ptr [ebp-4] ; k is loaded
00401032 mov dword ptr [ebp-4],eax ; k is stored so that k =
k
00401035 mov ecx,dword ptr [ebp-4] ; k is loaded
00401038 add ecx,1 ; k is incremented
by 1
0040103B mov dword ptr [ebp-4],ecx ; incremented k is stored.
11:
12: printf("\n %d", k);
0040103E mov edx,dword ptr [ebp-4]
00401041 push edx
00401042 push offset string "\n %d" (0042001c)
00401047 call printf (004010b0)
0040104C add esp,8

Yes, its a kind of vague that assignment is happening before increment.
so its
k = k;
k = k + 1;

This is called postfix increament which is perfectly right...

which is okk.. i think i did mistake earlier by saying
k = k+ 1;
k = k;
since k++; means first assigment then increment.

u can see this code now...

00401026 rep stos dword ptr [edi]
7:
8: int k = 0;
00401028 mov dword ptr [ebp-4],0
9:
10: k = ++k;
0040102F mov eax,dword ptr [ebp-4] ; k is loaded
00401032 add eax,1 ; k is incremented
00401035 mov dword ptr [ebp-4],eax ; k is stored
00401038 mov ecx,dword ptr [ebp-4] ; k is loaded
0040103B mov dword ptr [ebp-4],ecx ; k is stored
11:

That is prefix increament...
This code has nothing to do with the OP code, and it's perfectly right,
google for postfix and prefix increament in C...

I'm really too lazy to go thro the whole 37 comments. I tried but they
lost me somewhere 20 -21.

OK, I'll try to summerize: It has undefined behaviour, period.
While you can compile the OP code with any C compiler and get some
results to argue with, this can't be confirmed on all compilers, or
worse in all cases.

Abdo Haji-Ali
Programmer
In|Framez

 

[Naresh]

That is prefix increament...
This code has nothing to do with the OP code, and it's perfectly right,
google for postfix and prefix increament in C...

Thank you for being patient; i know what is post and pre increment and
so does the compiler, at least msvc6 knows this for sure, which it
implies very very clearly in the generated asm, atleast i can infer so.
I'm not imbibing asm in C but just showing how msvc6 assembler is
working after no compilation errors.

OK, I'll try to summerize: It has undefined behaviour, period.
While you can compile the OP code with any C compiler and get some
results to argue with, this can't be confirmed on all compilers, or
worse in all cases.

If this cant be confirmed on all the compilers then is that the problem
or loophole in C standard (like undefined behavior) or a bug in that
compiler? Compilers/assemblers should go in accordance with the
standard not the vice-versa. This cooresponding ASM clearly works in
accordance to standard, at least it looks to me. And i m justified in
considering asm because C is middle level language.

Just by saying that the behavior is undefined never makes it undefined.
I'm getting consistent results and the consistent opcode generation at
least for this piece of code.

I'm still wondering how can it be undefined. A piece of code, which
behaves erratic using these simple assignment, will help me to
understand it better. I should get conflicting (undefined) results for
the same equation. I've msvc6 installed on win2000.

Thanks n Regards,
Naresh

 

[Abdo Haji-Ali]

That is prefix increament...

This code has nothing to do with the OP code, and it's perfectly right,
google for postfix and prefix increament in C...

Intersting, I just read Gordon's link, and it seems that this code too
has undefined behaviour according to the standard... Sorry

Abdo Haji-Ali
Programmer
In|Framez

 

[Naresh]

Intersting, I just read Gordon's link, and it seems that this code too
has undefined behaviour according to the standard... Sorry

Thank you, i just understood, that

"b]etween the previous and next sequence point an object shall have its
stored value modiï¬ed at most once by the evaluation of an
expression."

and hence even simple assignment is considered as modification. Hence
forth, according to standard, u can never have two assignments within a
single statement (like i = i++, thou, it may invariably be possible
for all the existing compilers ( or at least msvs6 on win2000) to
assign it properly and consistently.

I hope my above assignment statement is true.

Regards,
Naresh

 

[Naresh]

The compiler can do that, or can can treat it as an instruction to
launch a nuclear strike against darkest Peru, which might upset a
certain bear.

haha, yes, if u go like schrodinger, possibility of a nuclear strike
exist.
It is really undefined behaviour.

Note that with undefined behaviour compilers are allowed to treat it in
the way you happen to expect it, but it might do something different
later, or if you change compiler options, or if you make a seemingly
unrelated change, or if you upgrade the compiler, or if you are trying
to demonstrate it to your boss.

It has not done anything different yet, i believe it wont do anything
different even if i show it to president of US or pull out a gun at the
screen!
Thou' now, i understood ur predefined path of "go in accordance to the
standard." Yes, it is undefined.

Thanks n Regards,
Naresh