5 ms·

I'd love to see a compiler warn me that it's doing something potentially unexpected due to UB considerations.

by TwoBit 7y ago

saagarjha 7y ago
Luckily, compiler authors have gotten the message and are starting to improve on this situation slowly.
ali_m 7y ago
clang has UBSan, which adds runtime checks for detecting various kinds of undefined behaviour: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
- codys 7y ago
  gcc also has ubsan since gcc version 4.9. Many of the sanitizers are shared by the clang & gcc projects. Some functionality, like emitting errors on unsigned overflow, is confined to clang.
- rurban 7y ago
  That's not helping. I'm talking about wrong decisions, made during compile-time optimizations, like assuming dead code or a value being NULL, and then ripping apart the written code. Without warning. Or the famous optimized away memset call. Which is a security issue. At least a warning would be in order. Or at least an analyzer warning.
masklinn 7y ago
That is intrinsically limited because UB are runtime issues (otherwise they'd be compiler errors) and the compiler simply assumes they don't happen, plus many of the "UB-related" optimisations (in the sense that these optimisations change the behaviour of non-well-formed programs) are surfaced by other optimisations (largely inlining).
bluGill 7y ago
Problem is there are a lot of cases where the compiler doesnt know if the undefined behavior would happen in the real world. That is there is undefined behavior if some input parameter is out of range, and no way for the compiler to know that the input will always be in range - something I as a programmer with more global knowledge knows for sure which is why I don't check it.
Hello71 7y ago
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...: > warning: after 3 levels of inlining (potentially across files with Link Time Optimization), some common subexpression elimination, after hoisting this thing out of a loop and proving that these 13 pointers don't alias, we found a case where you're doing something undefined. This could either be because there is a bug in your code, or because you have macros and inlining and the invalid code is dynamically unreachable but we can't prove that it is dead.
thesz 7y ago
Gcc already (gcc-8) reports possible undefined behavior for loops and these are mostly out-of-bounds in my code. I like that a lot, actually, it save a ton of time.

I'd love to see a compiler warn me that it's doing something potentially unexpected due to UB considerations.

by TwoBit 7y ago

I'd love to see a compiler warn me that it's doing something potentially unexpected due to UB considerations.

saagarjha 7y ago

Luckily, compiler authors have gotten the message and are starting to improve on this situation slowly.

ali_m 7y ago

clang has UBSan, which adds runtime checks for detecting various kinds of undefined behaviour: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

codys 7y ago
gcc also has ubsan since gcc version 4.9. Many of the sanitizers are shared by the clang & gcc projects. Some functionality, like emitting errors on unsigned overflow, is confined to clang.
rurban 7y ago
That's not helping. I'm talking about wrong decisions, made during compile-time optimizations, like assuming dead code or a value being NULL, and then ripping apart the written code. Without warning. Or the famous optimized away memset call. Which is a security issue. At least a warning would be in order. Or at least an analyzer warning.

masklinn 7y ago

That is intrinsically limited because UB are runtime issues (otherwise they'd be compiler errors) and the compiler simply assumes they don't happen, plus many of the "UB-related" optimisations (in the sense that these optimisations change the behaviour of non-well-formed programs) are surfaced by other optimisations (largely inlining).

bluGill 7y ago

Problem is there are a lot of cases where the compiler doesnt know if the undefined behavior would happen in the real world. That is there is undefined behavior if some input parameter is out of range, and no way for the compiler to know that the input will always be in range - something I as a programmer with more global knowledge knows for sure which is why I don't check it.

Hello71 7y ago

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...: > warning: after 3 levels of inlining (potentially across files with Link Time Optimization), some common subexpression elimination, after hoisting this thing out of a loop and proving that these 13 pointers don't alias, we found a case where you're doing something undefined. This could either be because there is a bug in your code, or because you have macros and inlining and the invalid code is dynamically unreachable but we can't prove that it is dead.

thesz 7y ago

Gcc already (gcc-8) reports possible undefined behavior for loops and these are mostly out-of-bounds in my code. I like that a lot, actually, it save a ton of time.