4 ms·

One nice thing about undefined behavior is that it allows any behavior to be implemented, including diagnostics. So if your compiler has an option to do that (-

One nice thing about undefined behavior is that it allows any behavior to be implemented, including diagnostics. So if your compiler has an option to do that (-fsanitize=undefined) then you can make use of that to catch bugs. If you have defined wrapping/saturating semantics then you don't get this option, even if overflow is a bug in your program. AFAIK rust also panics on overflow in debug builds, so it's already decided that overflow is semantically a bug by default. So in release mode as it is already a bug then you potentially can't reason about the further behavior of the program. The compiler to assume that overflow doesn't happen and using that to optimize your program does not worsen the situation too much.

ithkuil 5y ago
fwiw, rust behaves differently between debug and release but in both cases the behaviour is defined. In release mode signed overflow is two-complement wraparound. You can use this fact to insert assertions that check if that happened and you won't be surprised that the compiler removes the check code you just wrote to check whether something happened! > The compiler to assume that overflow doesn't happen and using that to optimize your program does not worsen the situation too much. quite the contrary, the situation is much much worse! The C compiler silently removes code you may have written with the explicit intention of checking the effects of something. Yes sure you have bug; now with underfined behaviour you have an even harder time figuring out you have a bug in the first place! I'd be slightly less mad at C (copmilers) if it provided me a way of annotation a statement with "please don't optimize this out". But seriously, just don't exploit undefined behaviour. Programs have bugs; yes when a program hits a bug and continues you can say that the behaviour of the program is no longer defined according the the original intentions of the author. But wouldn't it be much much better if at least you can reason about what the program does according to how the (buggy) program is actually written? How mad would you be at a debugger that when asked to inspect the state of a variable that has been subjected to a signed overflow, would just lie to you and tell you it has a value it had some time in the past (or worse)?
temac 5y ago
Exploit UB to do optims can degenerate to the invocation of nasal deamons. I'm not sure to what extent it would theoritically be possible to avoid daemons while still providing some optimization, nor if any people even studied that question, but pragmatically: - complete violation and exploitation of the VM is a situation that Rust is trying to address as a main goal; - the main implementation using LLVM would make it hard to avoid unbounded consequences given the internal handling of UBs by llvm are rarely exploited with such constraints in mind.
cwzwarich 5y ago
> If you have defined wrapping/saturating semantics then you don't get this option, even if overflow is a bug in your program. Well, unsigned overflow is also a potential bug, and it's defined behavior. So if you want useful integer overflow diagnostics, you already need to break the C/C++ spec. Of course, the correct way to model this in a programming language is to distinguish between bitvectors with defined twos-complement operations and fixed-range integers.

ithkuil 5y ago

fwiw, rust behaves differently between debug and release but in both cases the behaviour is defined. In release mode signed overflow is two-complement wraparound. You can use this fact to insert assertions that check if that happened and you won't be surprised that the compiler removes the check code you just wrote to check whether something happened! > The compiler to assume that overflow doesn't happen and using that to optimize your program does not worsen the situation too much. quite the contrary, the situation is much much worse! The C compiler silently removes code you may have written with the explicit intention of checking the effects of something. Yes sure you have bug; now with underfined behaviour you have an even harder time figuring out you have a bug in the first place! I'd be slightly less mad at C (copmilers) if it provided me a way of annotation a statement with "please don't optimize this out". But seriously, just don't exploit undefined behaviour. Programs have bugs; yes when a program hits a bug and continues you can say that the behaviour of the program is no longer defined according the the original intentions of the author. But wouldn't it be much much better if at least you can reason about what the program does according to how the (buggy) program is actually written? How mad would you be at a debugger that when asked to inspect the state of a variable that has been subjected to a signed overflow, would just lie to you and tell you it has a value it had some time in the past (or worse)?

temac 5y ago

Exploit UB to do optims can degenerate to the invocation of nasal deamons. I'm not sure to what extent it would theoritically be possible to avoid daemons while still providing some optimization, nor if any people even studied that question, but pragmatically: - complete violation and exploitation of the VM is a situation that Rust is trying to address as a main goal; - the main implementation using LLVM would make it hard to avoid unbounded consequences given the internal handling of UBs by llvm are rarely exploited with such constraints in mind.

cwzwarich 5y ago

> If you have defined wrapping/saturating semantics then you don't get this option, even if overflow is a bug in your program. Well, unsigned overflow is also a potential bug, and it's defined behavior. So if you want useful integer overflow diagnostics, you already need to break the C/C++ spec. Of course, the correct way to model this in a programming language is to distinguish between bitvectors with defined twos-complement operations and fixed-range integers.