integer or long overflow...

Discussion in 'C++' started by deancoo, Mar 5, 2005.

  1. deancoo

    deancoo Guest

    When you increase the number contained within an integer or long data type
    beyond its capacity, what happens? I've run into this situation, and it
    continues right along. Is it simply just rolling over when it gets to its
    limit? Curious.

    d
    deancoo, Mar 5, 2005
    #1
    1. Advertising

  2. deancoo

    Phil Staite Guest

    deancoo wrote:
    > When you increase the number contained within an integer or long data type
    > beyond its capacity, what happens? I've run into this situation, and it
    > continues right along. Is it simply just rolling over when it gets to its
    > limit? Curious.


    I believe/suspect that like so many "edge effects" in C++ it is left
    undefined. However, a 2's compliment architecture (as most C++
    environments seem to be) will simply keep right on going - no
    exception/trap as from say dedicated floating point hardware
    experiencing a problem or say dividing by zero.

    The gotcha with 2's compliment is that if you increase a signed integer
    type (int or long) beyond it's limit, it becomes a very large negative
    number and keeps "increasing" - becoming less negative, headed towards zero.
    Phil Staite, Mar 5, 2005
    #2
    1. Advertising

  3. deancoo

    deancoo Guest

    "deancoo" <> wrote in message
    news:Tl8Wd.2338$KI2.178@clgrps12...
    > When you increase the number contained within an integer or long data type
    > beyond its capacity, what happens? I've run into this situation, and it
    > continues right along. Is it simply just rolling over when it gets to its
    > limit? Curious.
    >
    > d


    And how about emum types? Ultimately they're stored and compared as
    numbers, but what is their size? Short?

    d
    deancoo, Mar 5, 2005
    #3
  4. deancoo

    deancoo Guest

    "Phil Staite" <> wrote in message
    news:...
    > deancoo wrote:
    >> When you increase the number contained within an integer or long data
    >> type beyond its capacity, what happens? I've run into this situation,
    >> and it continues right along. Is it simply just rolling over when it
    >> gets to its limit? Curious.

    >
    > I believe/suspect that like so many "edge effects" in C++ it is left
    > undefined. However, a 2's compliment architecture (as most C++
    > environments seem to be) will simply keep right on going - no
    > exception/trap as from say dedicated floating point hardware experiencing
    > a problem or say dividing by zero.
    >
    > The gotcha with 2's compliment is that if you increase a signed integer
    > type (int or long) beyond it's limit, it becomes a very large negative
    > number and keeps "increasing" - becoming less negative, headed towards
    > zero.


    Would anyone in their right mind overflow a data type and still use it?
    Does it overflow consistently? I guess what I'm asking is, should I use it?
    What other options exist if you need to generate a number larger than 2^32,
    which is only used as a key for unique identification? I've already
    confirmed that for my finite set of data, the overflowed data type maintains
    uniqueness.

    d
    deancoo, Mar 5, 2005
    #4
  5. deancoo

    Prog37 Guest

    deancoo wrote:

    >
    > Would anyone in their right mind overflow a data type and still use it?
    > Does it overflow consistently? I guess what I'm asking is, should I use it?
    > What other options exist if you need to generate a number larger than 2^32,
    > which is only used as a key for unique identification? I've already
    > confirmed that for my finite set of data, the overflowed data type maintains
    > uniqueness.


    Does your unique key fit in 32 bits or not?
    Some c++ compilers gcc for instance offer the long long type.
    On a 32 bit platform this will be a 64 bit integer.
    The main drawback to using compiler extentions is the loss of portability.

    Another option would be to define a c++ class say:

    class BigInt
    {
    public:
    BigInt(int bits_storage);
    BigInt& operator + (BigInt);
    int& operator + (int);

    private:
    unsigned long *storage;
    int significant_bits;
    }

    I will leave the implementation as an excercise for the reader.
    Prog37, Mar 5, 2005
    #5
  6. deancoo

    deancoo Guest

    "Prog37" <> wrote in message
    news:...
    > deancoo wrote:
    >
    >>
    >> Would anyone in their right mind overflow a data type and still use it?
    >> Does it overflow consistently? I guess what I'm asking is, should I use
    >> it? What other options exist if you need to generate a number larger than
    >> 2^32, which is only used as a key for unique identification? I've
    >> already confirmed that for my finite set of data, the overflowed data
    >> type maintains uniqueness.

    >
    > Does your unique key fit in 32 bits or not?


    You see, the key that's generated has a large range, but is very disjointed.
    There are about 2.6M elements in a range as large as aprox. 4.7B. The key
    generator is super simple and super fast, so I don't want to change it. The
    only drawback, of course, is how disjointed the keys are, requiring a large
    container to hold them. When I said that the key maintains its uniqueness,
    what I meant was that even when the key generator produces a number in
    excess of 2^32, the resultant number stays unique compared to all other
    generated keys. So really, is it so bad to use this overflowed data type?
    Remember, I said finite set of data, and I've verified each possible key.
    deancoo, Mar 5, 2005
    #6
  7. On 5/3/05 1:35 PM, deancoo wrote:

    > Would anyone in their right mind overflow a data type and still use it?


    I have an application where I create bitmasks by doing this:

    unsigned int i32_BitMask = ( 1 << x ) - 1 ;

    where x is the number of 1 bits in the bitmask.

    In the case where x is 32, the 1 shifts off the left end of the 32-bit
    datum, and gives me precisely what I want.

    > What other options exist if you need to generate a number larger than 2^32,


    You can use a larger int type like long long (GCC) or _int64 (MSVC).
    Richard Cavell, Mar 5, 2005
    #7
  8. deancoo

    Prog37 Guest

    deancoo wrote:

    >
    > You see, the key that's generated has a large range, but is very disjointed.
    > There are about 2.6M elements in a range as large as aprox. 4.7B. The key
    > generator is super simple and super fast, so I don't want to change it. The
    > only drawback, of course, is how disjointed the keys are, requiring a large
    > container to hold them. When I said that the key maintains its uniqueness,
    > what I meant was that even when the key generator produces a number in
    > excess of 2^32, the resultant number stays unique compared to all other
    > generated keys. So really, is it so bad to use this overflowed data type?
    > Remember, I said finite set of data, and I've verified each possible key.
    >



    If I understand you correctly, you are saying that the key generator
    generates keys that have a dynamic range of zero to 4.7 billion.
    If this is correct you need a 33 bit unsigned integer to store the
    keys without discarding any bits of key data.

    ln(4.7x10^9)/ln(2) = 32.130013610776536155133366190146

    or

    2^32.130013610776536155133366190146 == 4.7 x 10^9


    But since the number of keys generated is small you think you can
    "risk it" and use the "overflowed data type".

    The obvious problem is that unless your key generator prevents it
    somehow there is a finite probability that multiple valid keys
    will map to the same "overflowed data" value.

    The only way your key generator could prevent that is if there
    were key ranges that were illegal for some reason. As an example
    if your key generator only produced even number keys that would
    reduce the randomness of the key generation by 1 bit so you could
    simply store key/2 in a 32 bit unsigned variable.

    If your key generation algorithm really requires 33 bits of storage
    it would be foolish to try to store it in 32 bits. You would be laying
    the groundwork for a bug that only surfaces once in a while. You can
    calculate the probabilities based on the number of keys generated.

    I hate trying to debug problems that only happen once in a while,
    I would much rather debug a repeatable bug. Just my 2 cents.

    knock 2 bits of randomness off of the key generation.
    In the example provided although the key could require 33 bits
    Prog37, Mar 5, 2005
    #8
  9. deancoo

    Prog37 Guest

    Richard Cavell wrote:
    > On 5/3/05 1:35 PM, deancoo wrote:
    >
    >> Would anyone in their right mind overflow a data type and still use it?

    >
    >
    > I have an application where I create bitmasks by doing this:
    >
    > unsigned int i32_BitMask = ( 1 << x ) - 1 ;
    >
    > where x is the number of 1 bits in the bitmask.
    >
    > In the case where x is 32, the 1 shifts off the left end of the 32-bit
    > datum, and gives me precisely what I want.
    >
    >> What other options exist if you need to generate a number larger than
    >> 2^32,

    >
    >
    > You can use a larger int type like long long (GCC) or _int64 (MSVC).


    For the problem he is describing he needs more than 32 bits (see my
    other post).

    One way of dealing with the portability issues introduced by 64 bit ints
    is to use conditional compilation. He could do something like.

    #ifdef WIN32
    typedef _int64 big_integer;
    #else
    typedef long long big_integer;
    #endif
    Prog37, Mar 5, 2005
    #9
  10. deancoo

    Pete Becker Guest

    deancoo wrote:
    > When you increase the number contained within an integer or long data type
    > beyond its capacity, what happens? I've run into this situation, and it
    > continues right along. Is it simply just rolling over when it gets to its
    > limit? Curious.
    >


    The behavior of overflow for signed itegral types is undefined. But for
    what you're doing it sounds like you should be using an unsigned type.
    On overflow the result is reduced modulo 2^n, where n is the number of
    bits in the value's representation.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
    Pete Becker, Mar 5, 2005
    #10
  11. deancoo

    Siemel Naran Guest

    "Pete Becker" <> wrote in message
    news:tPqdnXF8DvhAN7TfRVn-

    > The behavior of overflow for signed itegral types is undefined. But for
    > what you're doing it sounds like you should be using an unsigned type.
    > On overflow the result is reduced modulo 2^n, where n is the number of
    > bits in the value's representation.


    You mean LONG_MAX+1 would be zero, right? No overlfow exceptions?
    Siemel Naran, Mar 5, 2005
    #11
  12. deancoo

    Pete Becker Guest

    Siemel Naran wrote:
    > "Pete Becker" <> wrote in message
    > news:tPqdnXF8DvhAN7TfRVn-
    >
    >
    >>The behavior of overflow for signed itegral types is undefined. But for
    >>what you're doing it sounds like you should be using an unsigned type.
    >>On overflow the result is reduced modulo 2^n, where n is the number of
    >>bits in the value's representation.

    >
    >
    > You mean LONG_MAX+1 would be zero, right? No overlfow exceptions?
    >


    ULONG_MAX+1 is zero.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
    Pete Becker, Mar 5, 2005
    #12
    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. Dan Pop
    Replies:
    0
    Views:
    1,168
    Dan Pop
    Jun 24, 2003
  2. cyberdude
    Replies:
    2
    Views:
    5,104
    Keith Thompson
    Jun 25, 2003
  3. dmpk2k

    unsigned long long overflow?

    dmpk2k, Jul 9, 2003, in forum: C Programming
    Replies:
    7
    Views:
    639
    Emmanuel Delahaye
    Jul 18, 2003
  4. Tarique

    Unsigned Long Long Overflow

    Tarique, Feb 8, 2008, in forum: C Programming
    Replies:
    18
    Views:
    985
    christian.bau
    Feb 10, 2008
  5. Suresh V
    Replies:
    5
    Views:
    3,678
    SaticCaster
    Jul 5, 2010
Loading...

Share This Page