3 ms·

Regarding signed integer overflow > If it is implementation-defined, it is no longer considered an error by the C++ standard I do't understand why implementat

Regarding signed integer overflow > If it is implementation-defined, it is no longer considered an error by the C++ standard I do't understand why implementation defined can't be "throws exception/abort on overflow for debug build and something more efficient for release builds". Why do they need a new category for that?

virexene 3y ago
your compiler might choose to make that the "implementation-defined behavior", but another compiler could choose to always ignore it and give you no easy means of diagnosis. my understanding is that the proposal of "erroneous behavior" limits the scope of the consequences of triggering the behavior (like implementation-defined behavior), while still clearly marking it as erroneous and something to be diagnosed (like undefined behavior).
- Voultapher 3y ago
  I think I understand the motivation, but I'm not sure it is thought through. Taking the signed integer example, would platform defined wrapping be suitable behavior in the setting of erroneously defined behavior? If not, that would make it a poor fit for integer overflow, adding a branch to most signed integer math ops in release builds is a non starter for C++ projects. Regarding the diverse compiler point you made, that argument can be used to torpedo most ideas in this space. For example sanitizers started in clang, and now gcc and msvc have similar options, if something is a good idea, chances are the others will copy it. And relying on erroneously defined behavior (EB) to be a hard error, means relying on behavior that can differ across implementations and platforms which is problematic in itself. Plus, even relying on a hard error implies that EB has to be an error which is problematic for the reasons outlined above, or means it can't be used in the places you'd like to use it like signed integer overflow.
menaerus 3y ago
What new category? The article discusses the choice between having signed integer overflow as an implementation-defined and undefined behavior. And it says if it had been implementation-defined, it wouldn't be an error and hence UB sanitizer would not be able to catch it anymore. With signed integer overflow being the UB, sanitizers are able to catch them regardless of the level of optimization you apply to your code. "Debug" or "release". And what you propose, and what I think Rust does, is in no way better because "something more efficient" is ambiguous at its best. I wonder what would that be considering that is a condition that you certainly _want_ to catch. I think the reason why Rust did it this way (by panicking on the overflows in non-optimized builds) is because it does not have support for sanitizers (yet).
- UncleMeat 3y ago
  The new proposed category is "erroneous behavior", which allows for the sort of "this code is wrong so I refuse to compile" errors while also encouraging a sort of "I will at least treat this consistently if I compile it" behavior from the compiler. It remains to be seen whether or not the committee will accept any papers with this new category.
MaxBarraclough 3y ago
As others have pointed out, compilers are already free to do that if they wish. GCC has a flag to trap on signed integer overflow, [0] I believe Clang does too. Another option is to use a library like SafeInt [1] or Boost Safe Numerics [2] which offer drop-in replacement types like safe<int>. If you want to use raw unchecked integer types in release builds, you could do that using a typedef like my_int, in combination with a #if. [0] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html , the -ftrapv flag [1] https://github.com/dcleblanc/SafeInt https://github.com/dcleblanc/SafeInt [2] https://www.boost.org/doc/libs/release/libs/safe_numerics/doc/html/index.html https://www.boost.org/doc/libs/release/libs/safe_numerics/do...

virexene 3y ago

your compiler might choose to make that the "implementation-defined behavior", but another compiler could choose to always ignore it and give you no easy means of diagnosis. my understanding is that the proposal of "erroneous behavior" limits the scope of the consequences of triggering the behavior (like implementation-defined behavior), while still clearly marking it as erroneous and something to be diagnosed (like undefined behavior).

Voultapher 3y ago
I think I understand the motivation, but I'm not sure it is thought through. Taking the signed integer example, would platform defined wrapping be suitable behavior in the setting of erroneously defined behavior? If not, that would make it a poor fit for integer overflow, adding a branch to most signed integer math ops in release builds is a non starter for C++ projects. Regarding the diverse compiler point you made, that argument can be used to torpedo most ideas in this space. For example sanitizers started in clang, and now gcc and msvc have similar options, if something is a good idea, chances are the others will copy it. And relying on erroneously defined behavior (EB) to be a hard error, means relying on behavior that can differ across implementations and platforms which is problematic in itself. Plus, even relying on a hard error implies that EB has to be an error which is problematic for the reasons outlined above, or means it can't be used in the places you'd like to use it like signed integer overflow.

menaerus 3y ago

What new category? The article discusses the choice between having signed integer overflow as an implementation-defined and undefined behavior. And it says if it had been implementation-defined, it wouldn't be an error and hence UB sanitizer would not be able to catch it anymore. With signed integer overflow being the UB, sanitizers are able to catch them regardless of the level of optimization you apply to your code. "Debug" or "release". And what you propose, and what I think Rust does, is in no way better because "something more efficient" is ambiguous at its best. I wonder what would that be considering that is a condition that you certainly _want_ to catch. I think the reason why Rust did it this way (by panicking on the overflows in non-optimized builds) is because it does not have support for sanitizers (yet).

UncleMeat 3y ago
The new proposed category is "erroneous behavior", which allows for the sort of "this code is wrong so I refuse to compile" errors while also encouraging a sort of "I will at least treat this consistently if I compile it" behavior from the compiler. It remains to be seen whether or not the committee will accept any papers with this new category.

MaxBarraclough 3y ago

As others have pointed out, compilers are already free to do that if they wish. GCC has a flag to trap on signed integer overflow, [0] I believe Clang does too. Another option is to use a library like SafeInt [1] or Boost Safe Numerics [2] which offer drop-in replacement types like safe<int>. If you want to use raw unchecked integer types in release builds, you could do that using a typedef like my_int, in combination with a #if. [0] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html , the -ftrapv flag [1] https://github.com/dcleblanc/SafeInt https://github.com/dcleblanc/SafeInt [2] https://www.boost.org/doc/libs/release/libs/safe_numerics/doc/html/index.html https://www.boost.org/doc/libs/release/libs/safe_numerics/do...