integer-overflow

问题 I have the following C code: uint8_t firstValue = 111; uint8_t secondValue = 145; uint16_t temp = firstValue + secondValue; if (temp > 0xFF) { return true; } return false; This is the alternative implementation: uint8_t firstValue = 111; uint8_t secondValue = 145; if (firstValue + secondValue > 0xFF) { return true; } return false; The first example is obvious, the uint16_t type is big enough to contain the result. When I tried the second example with the clang compiler on OS/X, it correctly

问题 Is there a safe way to reliably determine if an integral type T can store a floating-point integer value f (so f == floor(f) ) without any overflow? Keep in mind that there is no guarantee that the floating point type F is IEC 559 (IEEE 754) compatible, and that signed integer overflow is undefined behavior in C++. I'm interested in a solution which is correct according to the current C++ (C++17 at the writing) standard and avoids undefined behavior . The following naive approach is not

问题 Per the specification of strtol : If the subject sequence has the expected form and the value of base is 0, the sequence of characters starting with the first digit shall be interpreted as an integer constant. If the subject sequence has the expected form and the value of base is between 2 and 36, it shall be used as the base for conversion, ascribing to each letter its value as given above. If the subject sequence begins with a minus-sign, the value resulting from the conversion shall be

问题 I have this code segment: #include <stdio.h> int main(int argc, const char** argv) { int a = argv[0][0]; int b = argv[0][1]; while ((a >= 0) && (a < b)) { printf("a = %d\n", a); a++; } return 0; } and I'm compiling it with gcc-4.5 -02 -Wstrict-overflow=5 . The compiler yells at me warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 What does this mean exactly? If i am correct, this loop will never cause an overflow, because for a to be incremented,

问题 Let's consider the function (one of possible implementations of it) which would zero out right N bits of an unsigned short value (or any other unsigned integral type). The possible implementation could look like following: template<unsigned int shift> unsigned short zero_right(unsigned short arg) { using type = unsigned short; constexpr type mask = ~(type(0)); constexpr type right_zeros = mask << shift; // <-- error here return arg & right_zeros; } int check() { return zero_right<4>(16); }

问题 I know that (INT_MIN / -1) overflows, but (INT_MIN % -1) does not. At least this is what happens in two compilers, one pre-c++11 (VC++ 2010) and the other post-c++11 GCC 4.8.1 int x = INT_MIN; cout << x / -1 << endl; cout << x % -1 << endl; Gives: -2147483648 0 Is this behavior standard defined or this is implementation defined? Also is there ANY OTHER case where the division operation would overflow? and is there any case where the modulus operator would overflow? 回答1: According to CERT C++

问题 I wrote a method to convert a given number from days to milliseconds: private long expireTimeInMilliseconds; ... public void setExpireTimeInDays(int expireTimeInDays) { expireTimeInMilliseconds = expireTimeInDays * 24 * 60 * 60 * 1000; } I had a hard time to figure out what I did wrong. Now my question: Is that error so obvious ? The corrected method: private long expireTimeInMilliseconds; ... public void setExpireTimeInDays(int expireTimeInDays) { expireTimeInMilliseconds = ((long)

问题 Whenever I need to average two numbers for an algorithm like binary search, I always do something like this: int mid = low + ((high - low) / 2); I recently saw another way to do it in this post, but I don't understand it. It says you can do this in Java: int mid = (low + high) >>> 1; or this in C++: int mid = ((unsigned int)low + (unsigned int)high)) >> 1; The C++ version essentially makes both operands unsigned, so doing a shift results in an arithmetic shift instead of a signed shift. I

问题 No, this is not a duplicate of How to detect integer overflow?. The issue is the same but the question is different. The gcc compiler can optimize away an overflow check (with -O2), for example: int a, b; b = abs(a); // will overflow if a = 0x80000000 if (b < 0) printf("overflow"); // optimized away The gcc people argue that this is not a bug. Overflow is undefined behavior, according to the C standard, which allows the compiler to do anything . Apparently, anything includes assuming that

问题 I want to add numpy arrays with datatyp uint8. I know that the values in these arrays may be large enough for an overflow to happen. So I get something like: a = np.array([100, 200, 250], dtype=np.uint8) b = np.array([50, 50, 50], dtype=np.uint8) a += b Now, a is [150 250 44] . However, instead of an overflow I want values which are too large for uint8 to be the maximum allowed for uint8. So my desired result would be [150 250 255] . I could get this result with the following code: a = np