429,334 Members | 2,776 Online
+ 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
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" 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 San Diego Supercomputer Center <*> 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 doint 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 doint 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 San Diego Supercomputer Center <*> 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" writes: 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 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 San Diego Supercomputer Center <*> 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 > 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 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 San Diego Supercomputer Center <*> 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 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 wrote:what is supposed to doint 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: 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" 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 San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 12 '06 #24

 P: n/a "Naresh" 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 San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 12 '06 #25

 P: n/a Naresh wrote: #include 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 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" 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 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" 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 . (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 San Diego Supercomputer Center <*> 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 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 wrote:On Tue, 11 Apr 2006 22:46:47 +0200, RSoIsCaIrLiIoA wrote:what is supposed to doint 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" 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" 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" 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 wrote: Herbert Rosenau wrote: On Thu, 13 Apr 2006 17:56:59 UTC, "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.