By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,334 Members | 2,776 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,334 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Apr 11 '06 #1
Share this Question
Share on Google+
35 Replies


P: n/a
RSoIsCaIrLiIoA wrote:
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.
Apr 11 '06 #2

P: n/a
RSoIsCaIrLiIoA wrote:
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...valorder1.html

Xicheng
thank U


Apr 11 '06 #3

P: n/a

RSoIsCaIrLiIoA wrote:
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/micro...c4d4d9039ea004

Abdo Haji-Ali
Programmer
In|Framez

Apr 11 '06 #4

P: n/a
void * clvrmnky() wrote:
RSoIsCaIrLiIoA wrote:
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

Apr 11 '06 #5

P: n/a
Xicheng Jia wrote:
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
Apr 11 '06 #6

P: n/a
Abdo Haji-Ali wrote:

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
Apr 11 '06 #7

P: n/a
"Abdo Haji-Ali" <ah***@inframez.com> writes:
RSoIsCaIrLiIoA wrote:
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/micro...c4d4d9039ea004


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 11 '06 #8

P: n/a
RSoIsCaIrLiIoA wrote:
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.

Apr 12 '06 #9

P: n/a
ch*******@gmail.com writes:
RSoIsCaIrLiIoA wrote:
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 12 '06 #10

P: n/a

Keith Thompson wrote:
"Abdo Haji-Ali" <ah***@inframez.com> writes:

<snip RSoIsCaIrLiIoA's trolling>

This might be a useful link for you:
http://groups.google.com/group/micro...c4d4d9039ea004


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.

Apr 12 '06 #11

P: n/a

Keith Thompson wrote:
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
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.


Apr 12 '06 #12

P: n/a
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[i] +
a[i+1]; could be interpreted by the compiler as:

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

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

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

Abdo Haji-Ali
Programmer
In|Framez

Apr 12 '06 #13

P: n/a
Abdo Haji-Ali wrote:
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[i] +
a[i+1]; could be interpreted by the compiler as:

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

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


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
Abdo Haji-Ali
Programmer
In|Framez


Apr 12 '06 #14

P: n/a
> 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

Apr 12 '06 #15

P: n/a
Naresh wrote:
Keith Thompson wrote:
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.


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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.


Please don't quote peoples sigs (i.e. the bit above which you quoted)
unless you are commenting on them.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Apr 12 '06 #16

P: n/a

Abdo Haji-Ali wrote:
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.
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.


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
Programmer
In|Framez


Apr 12 '06 #17

P: n/a
> 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

Apr 12 '06 #18

P: n/a

Abdo Haji-Ali wrote:
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


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
Abdo Haji-Ali
Programmer
In|Framez


Apr 12 '06 #19

P: n/a

Flash Gordon wrote:
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.

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

Apr 12 '06 #20

P: n/a
Naresh wrote:

Keith Thompson wrote:
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)


`main` should return `int`. The behaviour of your
code is undefined.
{
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.
Because it /is/ undefined behaviour - the standard does not specify
any particular behaviour for this expression (`k = k++`). An implementation
may issue a warning, it may reject the code, it may print 17, it may
delete your files.
Isnt it ok
to consider it as two statements as

k = k + 1;
k = k;


It's also OK to consider it as the two statements:

k = -1;
k = -2;

Or as a double-effect machine instruction [1]

mov k k | add k k #1

which does both operations in parallel and, if it so happens that
the target register is the same in both instructions, fills it
with the bitwise OR of the results. This gets your expected result,
but for

int k = 1;
k = k++;

will put 3 into k.

Of course a later architecture, noting that allowing multiple
writes to the same register was silly and that no compiler
would generate it, arranged that such instructions were
co-processor invocations to co-processor `k`, and now your
program attempts to do an FFT where the `k #1` part of the
instructions specifies the array address and breaks because
the address is illegal.

BOOM tomorrow. There's always a BOOM tomorrow.

[1] For an architecture which I have made up, but which isn't
necessarily stupid.

--
Chris "not a Tuvela" Dollin
"To say that the human is thus and so is almost always to lie
automatically."
Apr 12 '06 #21

P: n/a
On Tue, 11 Apr 2006 22:46:47 +0200, RSoIsCaIrLiIoA <zz@zz.z> wrote:
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];
no, i would like to say here
"return a[j]"
}

what will be the return value?
thank U

Apr 12 '06 #22

P: n/a
Naresh wrote:
Abdo Haji-Ali wrote:
<snip>
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.


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.


If the C standard, the one and only document that defines what C is,
says something is undefined, then it is undefined. Period. Enod of
discussion.

In English, "wombat yellow banana thing purple of to in at but" is
meaningless, yet I can type it and my editor (which does spell checking)
doesn't complain. "Just by saying it is meaningless does not make it
meaningless".
I'm getting consistent results and the consistent opcode generation at
least for this piece of code.
"Every time I cross the street with my eyes closed and ear defender on
so I can't see anything nothing goes wrong."

Undefined behaviour is like that. It is not defined. Not defined does
not mean it will get you run over, but one day it might and you will
have no one but yourself to blame.

Even if we gave you a simple piece of code that behaves unpredictably on
all of our systems it could produce the same result every time you try it.
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.


No, with undefined behaviour you can get *anything*. That includes the
same behaviour every time you do it. However, tomorrow when you run it
your computer could hack in to the CIA's computers and add an entry
saying that you are the most dangerous terrorist on the planet. Or it
could cause demons to fly out of your nose.
Abdo Haji-Ali
Programmer
In|Framez


Please don't quote peoples signatures, only quote the material you are
commenting on.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Apr 12 '06 #23

P: n/a
"Naresh" <na**********@gmail.com> writes:
[...]
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.


There is no proper and consistent behavior for "i = i++;". As the
standard joke goes, it can legally make demons fly out of your nose.
(This obviously isn't possible, but if it did happen you couldn't
complain that the compiler is non-conforming.)

Even if it were well defined, it would probably mean one of two
things: increment i and then assign the old value of i to i (which
does nothing), or assign the old value of i to i and then increment i
(which just increments i). Either way, there would be no reason to do
something convoluted like "i = i++;". If you just want to increment
i, use "i++;". If you want to do nothing, do nothing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 12 '06 #24

P: n/a
"Naresh" <na**********@gmail.com> writes:
[...]

(Context: "i = i++;".)
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.


This is *not* just a theoretical point. Optimizing compilers
rearrange expression evaluations to generate more efficient code. The
compiler is specifically allowed to *assume* that the code does not
invoke undefined behavior. If this assumption is incorrect (because
you lied to the compiler), the rearrangement can cause arbitrarily bad
things to happen.

Such things might not happen with something relatively simple like
"i = i++;", but each optimizing compiler is different, and you can't
assume *anything* about what can go wrong.

"If you lie to the compiler, it will get its revenge." -- Henry Spencer

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 12 '06 #25

P: n/a
Naresh wrote:
#include<stdio.h>

void main(void)
{
int k = 0;
k = k++;
printf("\n %d", k);
}

It gives me expected outcome as 1
There is no such thing as "expected outcome" from your program.
on msvc 6 without any warnings or
errors.
Then your compiler is broken or you have failed to properly set the
diagnostic level. Consider the diagnostics given by gcc below. They
are, by the way, *mildly* worded. These "warnings" flag clear errors:

#include <stdio.h>

void main(void)
/* warning: return type of 'main' is not 'int' */
{
int k = 0;
k = k++;
/* warning: operation on 'k' may be undefined */
printf("\n %d", k);
}
Then, why should we call it as undefined behaviour.
Because it is undefined, and your are misusing both the C programming
language and your compiler. Isnt it ok
to consider it as two statements as

k = k + 1;
k = k;
No. If you mean that, write it, although a simple "k++;" statement
would do better.
It simply looks like Ra (register) = Ra + 1 and then Ra = Ra.


It simply looks like broken code from someone who thinks the return type
of main is void.
Apr 12 '06 #26

P: n/a
On Wed, 12 Apr 2006 13:19:41 UTC, "Naresh" <na**********@gmail.com>
wrote:

Abdo Haji-Ali wrote:
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.
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.


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.


That is because the compiler gets all fredom it needs from the
standard to create best code for its target mashine.

Read the fucking standard instead to cry "my compiiler what is the
only existent on the only hardware architecture prove that my mind is
right, so any other is wrong or buggy".

Your mind is crazy by NOT reading the standard and not able to
understund what 'undefined behavior' really means.

Even a = ++a; or a = a++; is undefined behavior because it modifies
the same variable more than once between 2 sequence points. It is the
decision of the compier if it will execute the increment before or
after it has done the assignment, but it will have done that before
the sequence point is reached.

You would never get a C programmer who is worth to get a job or gets
fired more quickly that you have gotten the job when you are unable to
accept that the standard is more clever than you will be in 1000
years.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
Apr 12 '06 #27

P: n/a
On Wed, 12 Apr 2006 16:17:40 UTC, Keith Thompson <ks***@mib.org>
wrote:
Such things might not happen with something relatively simple like
"i = i++;", but each optimizing compiler is different, and you can't
assume *anything* about what can go wrong.


Don't say that! Some years ago I had to port an 16 bit app to be 32
bit. It was easy don because the system API was not changed other than
to deliver 32 bit entries instead of 16 bit ones, but one point was
annoying me: the original developer was really lazy he used on some
points undefined behavior like i = i++; instead of i = i + 1; or
simply i++; and as the 32 bit compiler was using a better optimasion
even in debug mode than the old 16 bit one in memory optimasion the
program gaves strange results. It was hard work to find out why the
data was significant irreparable defective it had produced. The
program was only about 20 compilation units with each of 200 - 250
lines of code in it.

The OP seems to be one of that kind of peoples who have decided that
the know of all and anything and unable to learn. He laughts on you
when you tries to help him to learn what 'undefines behavior means'.
He has prepared himself already to be plonkeked based on his learn
resistence.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
Apr 12 '06 #28

P: n/a
the answer is 3

Apr 13 '06 #29

P: n/a
"sh***********@gmail.com" <sh***********@gmail.com> writes:
the answer is 3


No.

Without context, it's difficult to tell what you're talking about.
Not everyone can easily see the article to which you're replying.
Please read <http://cfaj.freeshell.org/google/>. (If you had taken a
look a this newsgroup before posting, as you should have, you would
already know that.)

But since you're using groups.google,com, and you *can* easily see the
rest of the discussion, you should know that the program in the
orginal article invokes undefined behavior. There is no such thing as
"the answer".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 13 '06 #30

P: n/a

Naresh wrote:
Keith Thompson wrote:
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.


Because there's no guarantee that the result will be 1 on another
platform, or on the same platform with a different compiler, or the
same platform and compiler with different options.

Because I was bored one day, I wrote a series of programs that went
through all the permutations of j = i++ + i++, j = i++ + ++i, etc., and
compiled them for both Windows NT (using Visual Studio) and MacOS
(using MPW). On both platforms, at least one permutation gave a
"wrong" result, and the "wrong" results were different between the two
platforms.

When we say the behavior is undefined, we mean that the compiler is
under no obligation to generate a correct result. Just because you get
the result you expect doesn't mean that the code is correct.
Isnt it ok to consider it as two statements as

k = k + 1;
k = k;


Strictly speaking, no. With the expression "k = k++", there's no
guarantee that the side effect will be applied before the assignment.

In short, for expressions like "k = k++", there is *no* correct result.

Apr 14 '06 #31

P: n/a
On Wed, 12 Apr 2006 17:57:06 +0200, RSoIsCaIrLiIoA <zz@zz.z> wrote:
On Tue, 11 Apr 2006 22:46:47 +0200, RSoIsCaIrLiIoA <zz@zz.z> wrote:
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];


no, i would like to say here
"return a[j]"
}

what will be the return value?
thank U


thank you
Apr 14 '06 #32

P: n/a
On Thu, 13 Apr 2006 17:56:59 UTC, "sh***********@gmail.com"
<sh***********@gmail.com> wrote:
the answer is 3


Not true. The answer is always 42.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
Apr 15 '06 #33

P: n/a
Herbert Rosenau wrote:
On Thu, 13 Apr 2006 17:56:59 UTC, "sh***********@gmail.com"
<sh***********@gmail.com> wrote:

the answer is 3

Not true. The answer is always 42.

But only if you calculate that with a goobleplex computer.
Apr 15 '06 #34

P: n/a
Sjouke Burry wrote:
Herbert Rosenau wrote:
On Thu, 13 Apr 2006 17:56:59 UTC, "sh***********@gmail.com"
<sh***********@gmail.com> wrote:

the answer is 3

Not true. The answer is always 42.

But only if you calculate that with a goobleplex computer.


It doesn't really matter. The computer always gets the answer wrong.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Apr 15 '06 #35

P: n/a
On 2006-04-15, Sjouke Burry <bu*************@ppllaanneett.nnlll> wrote:
Herbert Rosenau wrote:
On Thu, 13 Apr 2006 17:56:59 UTC, "sh***********@gmail.com"
<sh***********@gmail.com> wrote:

the answer is 3

Not true. The answer is always 42.

But only if you calculate that with a goobleplex computer.


I thought you had to do the calculations on a waiter's cheque writing
pad.

Apr 16 '06 #36

This discussion thread is closed

Replies have been disabled for this discussion.