Why would this crash?

Discussion in 'C++' started by JoeC, Apr 15, 2010.

  1. JoeC

    JoeC Guest

    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?
     
    JoeC, Apr 15, 2010
    #1
    1. Advertising

  2. JoeC

    Jorgen Grahn Guest

    On Thu, 2010-04-15, Daniel T. wrote:
    > JoeC <> wrote:
    >
    >> 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.

    >
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Apr 15, 2010
    #2
    1. Advertising

  3. JoeC

    JoeC Guest

    On Apr 15, 11:01 am, Jorgen Grahn <> wrote:
    > On Thu, 2010-04-15, Daniel T. wrote:
    > > JoeC <> wrote:

    >
    > >> 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.

    >
    > > 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
    >
    > --
    >   // Jorgen Grahn <grahn@  Oo  o.   .  .
    > \X/     snipabacken.se>   O  o   .



    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, Apr 15, 2010
    #3
  4. JoeC

    JoeC Guest

    On Apr 15, 6:51 am, "Daniel T." <> wrote:
    > JoeC <> wrote:
    > > 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.

    >
    > 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, Apr 15, 2010
    #4
  5. JoeC

    JoeC Guest

    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.
     
    JoeC, Apr 15, 2010
    #5
  6. JoeC wrote:
    > 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
     
    James Lothian, Apr 15, 2010
    #6
  7. JoeC

    Öö Tiib Guest

    On 15 apr, 22:16, JoeC <> wrote:
    > On Apr 15, 6:51 am, "Daniel T." <> wrote:
    >
    > > JoeC <> wrote:
    > > > 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.

    >
    > > 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 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.
     
    Öö Tiib, Apr 15, 2010
    #7
  8. JoeC

    JoeC Guest

    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.
     
    JoeC, Apr 16, 2010
    #8
  9. JoeC

    Helge Kruse Guest

    "JoeC" <> wrote in message
    news:...
    >
    >
    > 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
     
    Helge Kruse, Apr 16, 2010
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Armel HERVE

    Why a crash ?

    Armel HERVE, Sep 29, 2003, in forum: Java
    Replies:
    10
    Views:
    714
    Armel HERVE
    Sep 30, 2003
  2. Alf P. Steinbach

    Re: Why does this crash?

    Alf P. Steinbach, Jul 18, 2003, in forum: C++
    Replies:
    5
    Views:
    381
  3. Developwebsites

    why does it crash?

    Developwebsites, Oct 10, 2003, in forum: C++
    Replies:
    6
    Views:
    370
    Jerry Coffin
    Oct 11, 2003
  4. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    998
    Mark Rae
    Dec 21, 2006
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,270
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page