3 ms·

Even if the current INT_MIN were redefined to be a NaN or a trap, that would do almost nothing to prevent signed integer overflow bugs. Sure, INT_MAX + 1 would

Even if the current INT_MIN were redefined to be a NaN or a trap, that would do almost nothing to prevent signed integer overflow bugs. Sure, INT_MAX + 1 would be an error, but INT_MAX+2, INT_MAX+100 and so on would still be equal to INT_MIN + 1, INT_MIN + 99 etc. Besides, -fwrapv was basically the default in most C compilers (and probably C++ as well) before the last 10 years or so. Many large systems thus use it today as well (e.g. the Linux kernel, I believe).

trealira 3y ago
> Besides, -fwrapv was basically the default in most C compilers (and probably C++ as well) before the last 10 years or so. It seems like people were complaining as early as 2007. Richard Biener (who's linked in the thread link below) said that GCC 2.95.3, which came in 2001, optimized away signed overflow checks as well. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- > signed type overflow is undefined by the C standard, use unsigned int for the > addition or use -fwrapv You have GOT to be kidding? All kinds of security issues are caused by integer wraps, and you are just telling me that with gcc 4.1 and up I cannot test for them for signed data types any more?! You are missing the point here. There HAS to be a way to get around this. Existing software uses signed int and I can't just change it to unsigned int, but I still must be able to check for a wrap! There does not appear to be a work around I could do in the source code either! Do you expect me to cast it to unsigned, shift right by one, and then add or what?! PLEASE REVERT THIS CHANGE. This will create MAJOR SECURITY ISSUES in ALL MANNER OF CODE. I don't care if your language lawyers tell you gcc is right. THIS WILL CAUSE PEOPLE TO GET HACKED. I found this because one check to prevent people from getting hacked failed. THIS IS NOT A JOKE. FIX THIS! NOW!
- simiones 3y ago
  Thanks for looking into the history! Interesting to see that this wrong-headed behavior has now been around in GCC for longer than the status quo before. Other compilers are different though - MSVC only seems to have started optimizing around this in ~2016 or so, icc seems to have done something around this in 2020, and I'm sure many embedded compilers ignore it even today. I couldn't find anything definitive on clang, but given its history I assume it probably always enforced this mistake. I'd also note that several major C programs only work when signed integer overflow is defined: I mentioned Linux previously, but Python is another one. And Chrome and Firefox are considering enabling -fwrapv and equivalents.
  - deleted 3y ago
    [deleted]
  - trealira 3y ago
    Yeah, you're definitely right that a lot of C and C++ code is written assuming signed overflow won't be optimized away. I think it was a mistake of GCC to do this optimization without some explicit flag like "-fremove-signed-overflow". I wish they didn't do that, but it's not up to me what they do. It's necessary for optimizations like loop unrolling, auto-vectorization, and compiling "for (int i = 0; i < N; i++)" as if it were written "for (size_t i = 0; i < N; i++)" when it's more efficient to do so, but again, I think this should be opt-in, and either -fwrapv or -ftrapv should be default on the generic -O1, -O2, -O3 levels.

trealira 3y ago

> Besides, -fwrapv was basically the default in most C compilers (and probably C++ as well) before the last 10 years or so. It seems like people were complaining as early as 2007. Richard Biener (who's linked in the thread link below) said that GCC 2.95.3, which came in 2001, optimized away signed overflow checks as well. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- > signed type overflow is undefined by the C standard, use unsigned int for the > addition or use -fwrapv You have GOT to be kidding? All kinds of security issues are caused by integer wraps, and you are just telling me that with gcc 4.1 and up I cannot test for them for signed data types any more?! You are missing the point here. There HAS to be a way to get around this. Existing software uses signed int and I can't just change it to unsigned int, but I still must be able to check for a wrap! There does not appear to be a work around I could do in the source code either! Do you expect me to cast it to unsigned, shift right by one, and then add or what?! PLEASE REVERT THIS CHANGE. This will create MAJOR SECURITY ISSUES in ALL MANNER OF CODE. I don't care if your language lawyers tell you gcc is right. THIS WILL CAUSE PEOPLE TO GET HACKED. I found this because one check to prevent people from getting hacked failed. THIS IS NOT A JOKE. FIX THIS! NOW!

simiones 3y ago
Thanks for looking into the history! Interesting to see that this wrong-headed behavior has now been around in GCC for longer than the status quo before. Other compilers are different though - MSVC only seems to have started optimizing around this in ~2016 or so, icc seems to have done something around this in 2020, and I'm sure many embedded compilers ignore it even today. I couldn't find anything definitive on clang, but given its history I assume it probably always enforced this mistake. I'd also note that several major C programs only work when signed integer overflow is defined: I mentioned Linux previously, but Python is another one. And Chrome and Firefox are considering enabling -fwrapv and equivalents.
- deleted 3y ago
  [deleted]
- trealira 3y ago
  Yeah, you're definitely right that a lot of C and C++ code is written assuming signed overflow won't be optimized away. I think it was a mistake of GCC to do this optimization without some explicit flag like "-fremove-signed-overflow". I wish they didn't do that, but it's not up to me what they do. It's necessary for optimizations like loop unrolling, auto-vectorization, and compiling "for (int i = 0; i < N; i++)" as if it were written "for (size_t i = 0; i < N; i++)" when it's more efficient to do so, but again, I think this should be opt-in, and either -fwrapv or -ftrapv should be default on the generic -O1, -O2, -O3 levels.