## undetermination?

Write here if you have problems with your C source code

Moderator: Board moderators

jakabjr
Learning poster
Posts: 56
Joined: Wed Mar 23, 2005 9:21 pm
Location: Timisoara, Romania

### undetermination?

I used this piece of code in a program the other days and it took me about an hour to find the bug:

Code: Select all

``````while(i<j) a[i++] = a[j--];
``````
Replacing with {a=a[j]; i++; j++} made the code run correctly.

My real problem now is that i knew this is NOT a bug. I'm guessing I've got some kind of undetermination, but I can't tell why. It seems fairly logical that, since it's post-increment, I'll have a=a[j], and then the incerase...

Understanding a problem in a natural way will lead to a natural solution

misof
A great helper
Posts: 430
Joined: Wed Jun 09, 2004 1:31 pm

### Re: undetermination?

jakabjr wrote:I used this piece of code in a program the other days and it took me about an hour to find the bug:

Code: Select all

``````while(i<j) a[i++] = a[j--];
``````
Replacing with {a=a[j]; i++; j++} made the code run correctly.

You probably wanted to write { a=a[j]; i++; j--; }

jakabjr wrote:My real problem now is that i knew this is NOT a bug. I'm guessing I've got some kind of undetermination, but I can't tell why. It seems fairly logical that, since it's post-increment, I'll have a=a[j], and then the incerase...

Both versions do exactly the same on my machine.

Code: Select all

``````#include <stdio.h>
int a[20],i,j,k;

int main(void) {
for (k=18; k<=19; k++) {
for (i=0;i<20;i++) a[i]=i;
i=0; j=k;
while(i<j) a[i++] = a[j--];
for (i=0;i<20;i++) printf("%d ",a[i]); printf("\n");

printf("\n");

for (i=0;i<20;i++) a[i]=i;
i=0; j=k;
while(i<j) {a[i]=a[j]; i++; j--; }
for (i=0;i<20;i++) printf("%d ",a[i]); printf("\n");

printf("\n\n");
}
return 0;
}
``````
outputs

Code: Select all

``````18 17 16 15 14 13 12 11 10 9 10 11 12 13 14 15 16 17 18 19

18 17 16 15 14 13 12 11 10 9 10 11 12 13 14 15 16 17 18 19

19 18 17 16 15 14 13 12 11 10 10 11 12 13 14 15 16 17 18 19

19 18 17 16 15 14 13 12 11 10 10 11 12 13 14 15 16 17 18 19

``````
Isn't the problem actually somewhere else? Please give more details -- e.g. what is the type of a?

CDiMa
Experienced poster
Posts: 214
Joined: Fri Oct 17, 2003 5:49 pm
Location: Genova

### Re: undetermination?

jakabjr wrote:I used this piece of code in a program the other days and it took me about an hour to find the bug:

Code: Select all

``````while(i<j) a[i++] = a[j--];
``````
Replacing with {a=a[j]; i++; j++} made the code run correctly.

My real problem now is that i knew this is NOT a bug. I'm guessing I've got some kind of undetermination, but I can't tell why. It seems fairly logical that, since it's post-increment, I'll have a=a[j], and then the incerase...

Was the Online Judge misbehaving or your machine? What compiler do you use? Did you try with optimizations turned off?

Ciao!!!

Claudio

jakabjr
Learning poster
Posts: 56
Joined: Wed Mar 23, 2005 9:21 pm
Location: Timisoara, Romania
I'm sorry for my two mistakes before:
1. yes, it is j--;
2. I forgot to tell you that I use a Borland C++ compiler, version 3.1 and it's worked good so far. (I've also tried the code on Linux, but there it was no problem)

Yes, it's on my computer that's it's not working.
I could send you the whole code with outputs, if you think it would do you any good, but you probably have better things to do.

What optimizations do you mean?
Understanding a problem in a natural way will lead to a natural solution

CDiMa
Experienced poster
Posts: 214
Joined: Fri Oct 17, 2003 5:49 pm
Location: Genova
jakabjr wrote:I'm sorry for my two mistakes before:
1. yes, it is j--;
2. I forgot to tell you that I use a Borland C++ compiler, version 3.1 and it's worked good so far. (I've also tried the code on Linux, but there it was no problem)

Yes, it's on my computer that's it's not working.
I could send you the whole code with outputs, if you think it would do you any good, but you probably have better things to do.

What optimizations do you mean?
I don't know Borland's compiler, but usually compilers have switches to produce faster code optimizing the order of execution of instructions. Sometimes the optimizer goes "too far" and produces wrong code.
Since the code you posted relies on side effects of the post-decrement/increment operators, it's possible that optimizing it in the wrong way produces code that gives erroneous answers.

Ciao!!!

Claudio