this line executes fine
but this line crashes the programCode:g = p[x];
any idea why this could be?Code:g = p[x] >> 4;
this line executes fine
but this line crashes the programCode:g = p[x];
any idea why this could be?Code:g = p[x] >> 4;
What is g, p and x?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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?
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
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?
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Okay, do you know of any way to safeguard against these undefined behaviour problems?
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.
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?
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 . . . .Code:g = p[x]; g >>= 4;
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
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.