Why would this crash?

[JoeC]

I found a flaw in my logic I was using a BYTE type rather than an int
type but when I changed the type the program fails. I do ensure that
the number is allowed by the size of the array. num is the number I
will modify in the array. I works when it is a BYTE type it crashes
with an int type.

void bitmap::changeBit(int ac, int dn, BYTE col){

int up = 16-dn;
int num = (up*acc)+(current*16)+ac;

if((num < acc*dwn) || (num > 0)){
bits[num] = col;
}else{ MessageBox(NULL, "bang!", "Info", MB_OK);}
}

acc and dwn are the size of the array. I am using a flat array to
represent 2d object. I am simply trying to change the elements int he
array.

Why would I get an error from an int and not from a BYTE?

 

[Jorgen Grahn]

Along with what Paavo said, keep in mind that BYTE type is (in all
likelihood,) an unsigned type, while int is not. Sign conversion might
be causing problems in your code too.

To me, BYTE sounds signed -- with UBYTE as the unsigned version.
Maybe it's my Amiga programming background.

The *real* problem is of course that we have no way of knowing. Unless
it's a well-known Windows type or something.

/Jorgen

 

[JoeC]

To me, BYTE sounds signed -- with UBYTE as the unsigned version.
Maybe it's my Amiga programming background.

The *real* problem is of course that we have no way of knowing. Unless
it's a well-known Windows type or something.

/Jorgen

You do look familiar, I was an Amiga user until 2000. I wish I had
learned Amiga programming. I eventually had to get a PC because there
was too much I couldn't do.

 

[JoeC]

Along with what Paavo said, keep in mind that BYTE type is (in all
likelihood,) an unsigned type, while int is not. Sign conversion might
be causing problems in your code too.

I do realize that the sign conversiona and runnin over or under the
array can lead to problems. I do check for that.

I just used this:
BYTE num = (up*acc)+(current*16)+ac;

The program ran fine and with one block a 256 sized array it does not
crash. When I change BYTE to int it does crash. I do get stack
errors and debugging exceptions with the int.

I get a heap corruption with int and nothing with BYTE. The problem
is that BYTE only goes up to 256 and a larger number because my arrays
increase a 256 per added segment.

 

[JoeC]

thing can happen, including that the program can appear to work.

You should indeed learn how to step through the program in the debugger
and examine the variable values at each step. Then you could see by
yourself where exactly the things are starting to deviate from what you
expect.

Thanks for the suggestions.

 

[James Lothian]

I found a flaw in my logic I was using a BYTE type rather than an int
type but when I changed the type the program fails. I do ensure that
the number is allowed by the size of the array. num is the number I
will modify in the array. I works when it is a BYTE type it crashes
with an int type.

void bitmap::changeBit(int ac, int dn, BYTE col){

int up = 16-dn;
int num = (up*acc)+(current*16)+ac;

if((num< acc*dwn) || (num> 0)){
bits[num] = col;
}else{ MessageBox(NULL, "bang!", "Info", MB_OK);}
}

acc and dwn are the size of the array. I am using a flat array to
represent 2d object. I am simply trying to change the elements int he
array.

Why would I get an error from an int and not from a BYTE?

Probably because the result of the indexing operation
(up*acc)+(current*16)+ac isn't representable in a BYTE
(whose range will probably be 0..255 or -128..127, depending
on signedness). The restricted range of BYTE presumably stops
the result of the indexing from walking off the end of the
allocated memory. Once you switch to using int, which has
much wider range, the result is representable and you are
indexing off the end of the memory and UB ensues. So, either
the indexing calculation is wrong, or the memory block isn't
as big as you thought it was. Trace through it with the debugger.

James

 

[Öö Tiib]

I do realize that the sign conversiona and runnin over or under the
array can lead to problems.  I do check for that.

I just used this:
        BYTE num = (up*acc)+(current*16)+ac;

The program ran fine and with one block a 256 sized array it does not
crash.  When I change BYTE to int it does crash.  I do get stack
errors and debugging exceptions with the int.

I understand that bits are acc*dwn array. up is dwn-dn (you had
explicit 16 there but i feel you assume that dwn is 16). Other talks
indicate that the array size is 256 so probably that acc is also 16.

if to rewrite your formula using the assumptions above we get:
signed num = (up+current)*16 + ac;

So ... whenever dn < current it crashes. You tell no much about that
current, so no idea ... what it is.

 

[JoeC]

Thanks all for the help. It turns out that my function was giving me
negitave numbers and found and fixed them with the abs command.

 

[Helge Kruse]

Thanks all for the help. It turns out that my function was giving me
negitave numbers and found and fixed them with the abs command.

When your function was given negative numbers the contract to use this
function was probably violated. Are the arguments really "fixed" or are they
just move to any arbitrary values in the acceptable range?

You should consider to add an error check at the beginning of the function
if you can make sure that you get valid arguments. You dont need such a
check for each function. But at interface functions this might be necessary.

Helge