wierd problem

this line executes fine

Code:

---

g = p[x];

---

but this line crashes the program

Code:

---

g = p[x] >> 4;

---

any idea why this could be?

What is g, p and x?

Quote:

---

Originally Posted by Yarin

any idea why this could be?

---

You broke something.

If p[x] isn't a native type, perhaps your implementation of operator >> is broken.

Under normal circumstances, a right shift shouldn't crash . . . .

By "crash" do you mean a segmentation fault or something?

by crash I mean "this program has generated errors and must be closed by windows".

Code:

---

int x = 2;
BYTE p[1000];
BYTE b;

---

Is g an object of some type that you have overloaded the assignment operator?

I don't think I know what you mean, both g and p[] are BYTEs.

Do you have a minimal example program that exhibits the problem?

Definitely not that lines fault. The difference might be that the code generation is different, and when you use the shift operator, the code is using a different piece of code that EXPOSES an already existing undefined behaviour problem [such as overwriting the stack for example].

It is not entirely unusual that small code changes hides/exposes a problem elsewhere - but the problem isn't in the code that changed.

--
Mats

Okay, do you know of any way to safeguard against these undefined behaviour problems?

Quote:

---

Originally Posted by Yarin

this line executes fine

Code:

---

g = p[x];

---

but this line crashes the program

Code:

---

g = p[x] >> 4;

---

any idea why this could be?

---

Are you sure there is not some other simultaneous change which is causing x to have a different value?

What matsp described could be true, but IMHO it could only happen if you were doing incredibly weird things with memory. Is that the case?

Here is the code: http://members.ozemail.com.au/~dekker/NEUQUANT.C
The line "b = p[0] << netbiasshift;" is causing the crash. netbiasshift is defined as 4.

It seems that the code has already been deemed ready-to-use, so I am inclined to think that matsp is right. But how would I find where the problem code really is?

Thanks for the help so far.

Quote:

---

Originally Posted by Yarin

It seems that the code has already been deemed ready-to-use, so I am inclined to think that matsp is right. But how would I find where the problem code really is?

---

You would want to identify the specific memory access which led to the fault, and then trace that to a specific function, and from there, to a specific piece of data. Again, matsp's theory could be correct, but only if very strange things are occurring in memory. Otherwise, I honestly am baffled. Please try to reproduce the problem in as small a fragment of code as possible.

Not fixing the real problem, whatever that may be, but does this work?

Code:

---

g = p[x];
g >>= 4;

---

Also -- what kind of optimisations are you compiling with? That code looks highly mathematical, and sometimes, compilers can produce bad code with all manner of strange optimisations enabled . . . .

Now this makes me feel kind of dumb, the problem is that p was being incrimented as well as x, causing a read-error. The reason it worked without the bitshift, but not with it, still confuses me though. Thanks for the help.