C++ integer arithmetic overflow
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
Like OG, I don't use big integers. If I did need big integers, I would probably use a library that provided arbitrarily large numbers - certainly slower than CPU math, but at least 90% of the time acceptable. If you're in that gray area where you might get integer overflow, then you might use some of the techniques suggested on this SO page : [https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-integer-overflow\](https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-integer-overflow)
Keep Calm and Carry On
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
Requirements, architecture and design. So no detection but prevention. The business domain can insure that large sets cannot exist. Then from that there might be limited sets with the potential. So one must analyze the problem to insure the following. 1. Can it occur at all? 2. What is the timeline for when it can occur? 1 year? 10 years? 50 years? Myself I do not even attempt to program for long term problems which do not exist now. History does not suggest that doing that leads to better solutions - just ones that are more complex and harder to maintain. If I find that it can occur now then I use a solution that allows for that actually handles large numbers. There are multiple libraries that provide large number handling.
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
-
I have to be ill or something like that... :~ I agree with you :rolleyes: :-D :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I have to be ill or something like that... :~ I agree with you :rolleyes: :-D :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Hi Nelek Yes, you're right, somehow something isn't right anymore, it's changed. This is the second time you agree with me. And this after years of heated discussions I guess it's because I've finally grown up ;P :laugh: ;)
0x01AA wrote:
I guess it's because I've finally grown up ;-P
I would like to think than I have got younger... :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
0x01AA wrote:
I guess it's because I've finally grown up ;-P
I would like to think than I have got younger... :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
The usual way is after adding two positive numbers together, check if the result is negative. If it is, you've overflowed. You can also, if you're adding two 32-bit numbers together, cast them both to 64-bit, then add them and check if the resulting 64-bit value is greater than INT32_MAX. Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
Many moons ago, I was called in as consultant for a small business using Cobol and random access files for recording inventory transactions. Their main database file had been corrupted with new transactions overwriting existing transactions. I suspected integer oveflow. The field in the header record for the file was used to store the next free location. It was 16 bits so once they reached 65536 transactions the next free location was previously used. The Cobol number field was always positive so the roll over just went backwards. They were very surprised that 65536 transactions had occured. The coding fix was easy. I had to calculate the corrupted locations and restore the data from backups. Because I was still in Grad school, and the owner provided me extra pay for less hours so I could finish. True story.
"A little time, a little trouble, your better day" Badfinger
-
The usual way is after adding two positive numbers together, check if the result is negative. If it is, you've overflowed. You can also, if you're adding two 32-bit numbers together, cast them both to 64-bit, then add them and check if the resulting 64-bit value is greater than INT32_MAX. Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
Quote:
The usual way is after adding two positive numbers together, check if the result is negative. If it is, you've overflowed.
This doesn't work, because overflowing is undefined behaviour and the compiler is allowed to remove the check (i.e. it will never overflow). See this short snippet[^] The compiler completely removes the "overflow" path, so the check you propose *always* prints "Not overflowed".
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
Quote:
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
Determining overflow is not possible with signed integers (compiler is free to remove the check on signed integers, but has to keep the check for unsigned integers) so I try to use unsigned over signed wherever possible, and then I can check rollover using less-than/greater-than zero for overflow/underflow respectively. When I am forced to use signed (to interface to existing code), I use a larger integer than the interface specifies: use int16_t for 8 bit ints, int32_t for 16 bit ints, int64_t for 32 bit ints. For an interface that needs 64 bit ints I use the rollover/rollunder zero (using less-than and greater-than) after casting the signed 64 bit value to an unsigned 64 bit value. Under no circumstance is it safe to use plain `int` portably. All usage of plain `int` depends on the platform (hardware + compiler + OS combination), so you cannot write code that works now and in the future, you can only use the plain `int` type for code on a particular platform at a particular point in time - future versions of your platform have have a different sized `int`.
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
-
Quote:
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
Determining overflow is not possible with signed integers (compiler is free to remove the check on signed integers, but has to keep the check for unsigned integers) so I try to use unsigned over signed wherever possible, and then I can check rollover using less-than/greater-than zero for overflow/underflow respectively. When I am forced to use signed (to interface to existing code), I use a larger integer than the interface specifies: use int16_t for 8 bit ints, int32_t for 16 bit ints, int64_t for 32 bit ints. For an interface that needs 64 bit ints I use the rollover/rollunder zero (using less-than and greater-than) after casting the signed 64 bit value to an unsigned 64 bit value. Under no circumstance is it safe to use plain `int` portably. All usage of plain `int` depends on the platform (hardware + compiler + OS combination), so you cannot write code that works now and in the future, you can only use the plain `int` type for code on a particular platform at a particular point in time - future versions of your platform have have a different sized `int`.
Sorry for inadvertent click on inappropriate content
Joan F Silverston jsilverston@cox.net nhswinc.com
-
The usual way is after adding two positive numbers together, check if the result is negative. If it is, you've overflowed. You can also, if you're adding two 32-bit numbers together, cast them both to 64-bit, then add them and check if the resulting 64-bit value is greater than INT32_MAX. Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
As mentioned above, specifically undefined behavior might turn out in such a way that the "signed"ness does not necessarily flip as you would expect. Having said that, I don't know of a CPU/compiler that doesn't simply let the integers wrap around because that is still the easiest to implement. I was almost trying to propose some right-shift logic trick to check, but, the right-shift is, in fact, undefined for signed integers as well and may give invalid results. In assembly it's plain simple, you typically check the carry or overflow flag for unsigned or signed integers, respectively. Finally, a watertight solution would be to cut every integer in two halves using masks and shifts, then craft your own carry- and overflow logic. I'm too lazy to work it out in detail but I'm positive that all the information you need to detect overflow is in the high bits of the upper sum. Something like, upper half, or upper half + 1 bits must turn out equal, and if not, there is overflow.
-
An ounce of prevention is worth a pound of cure. Take either addend and subtract it from the maximum. If the result is smaller than the other addend, you will overflow. If Max - A < B, then A + B > Max // OVERFLOW
Whether an ounce is more than a pound depends on foreign imperial units, and scales that might overflow. Having said that, the method is properly defined in C(++) for unsigned all integers, using each their respective maximums, and easier than what I proposed.
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
There's many discussions of this on many StackOverflow and other threads. Some compilers support options to [enable throwing exceptions on overflow](https://stackoverflow.com/questions/3679047/integer-overflow-in-c-standards-and-compilers) including GCC (-ftrapv) or checked intrinsic options. If you're willing to wait, the [C23 standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf) includes a proposal for a stdckdint library with functions for performing checked integer math. Otherwise, you probably need to either find a 3rd party library that does this (or write your own methods where you can use one of many techniques depending on your performance requirements). Also, [C# supports checked expressions](https://stackoverflow.com/questions/2056445/no-overflow-exception-for-int-in-c) as either a compiler option or a local code block, in case that's an option.
-
There's many discussions of this on many StackOverflow and other threads. Some compilers support options to [enable throwing exceptions on overflow](https://stackoverflow.com/questions/3679047/integer-overflow-in-c-standards-and-compilers) including GCC (-ftrapv) or checked intrinsic options. If you're willing to wait, the [C23 standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf) includes a proposal for a stdckdint library with functions for performing checked integer math. Otherwise, you probably need to either find a 3rd party library that does this (or write your own methods where you can use one of many techniques depending on your performance requirements). Also, [C# supports checked expressions](https://stackoverflow.com/questions/2056445/no-overflow-exception-for-int-in-c) as either a compiler option or a local code block, in case that's an option.
i have written functions for addition and subtraction with signature
template requires integral&& integral&& integral sumType addition(augendType augend, addendType addend, OPTIONAL\_MATH\_CLIMITS\_TYPE(sumType) limits =EMPTY\_OPTIONAL\_MATH\_CLIMITS(sumType));it ensures if the requested result type can store the result no overflow will result no matter the argument size or sign . also variadic forms . these variadic forms minimize the chance of overflow by rearranging the arguments exempli gratia MAXINT + MAXINT - MAXINT becomes MAXINT - MAXINT + MAXINT . i am considering writing a variadic function which accepts all the arithmetic operators as arguments and utilizes the above techniques . my original post was to discern if such would be usefol to others and to learn of other options for myself .
-
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
I would suggest having a look at the built-in functions of the compilers that feature an overflow check. According to this post most recent compilers (GCC, Clang, Intel, MSVC) provide them. Documentation: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
bool __builtin_add_overflow (type1 a, type2 b, type3 *res)
bool __builtin_sub_overflow (type1 a, type2 b, type3 *res)
bool __builtin_mul_overflow (type1 a, type2 b, type3 *res)bool __builtin_add_overflow_p (type1 a, type2 b, type3 c)
bool __builtin_sub_overflow_p (type1 a, type2 b, type3 c)
bool __builtin_mul_overflow_p (type1 a, type2 b, type3 c)