10 ms·

It was LLVM, not Clang. And it is a really great idea to treat UB as "it never happened". Just do not rely on UB and always use static analysis.

by sklogic 11y ago

Kristine1975 11y ago
And turn on the Undefined Behavior Sanitizer (http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) with -fsanitize=undefined It would have caught this bug at run-time.
pjmlp 11y ago
If it was that easy. CppCon 2015, Herb Sutter's talk about writing safe code in C++14, just check how many in the audience use such tools. https://www.youtube.com/watch?v=hEx5DNLWGgA&feature=youtu.be&t=2053 https://www.youtube.com/watch?v=hEx5DNLWGgA&feature=youtu.be... A tiny 1%, this on the conference of with many of the top C++ developers. Now imagine how little they get used on the typical enterprise environment, specially worse with C, that lacks many of the C++ added safety layers.
barrkel 11y ago
Most C and C++ programmers' mental models of the machine is different to the abstract machine in the respective specifications. [1] There's a genuine problem here of overly clever optimizers wilfully misreading code to produce fast, wrong code. But the compiler exists to map our ideas into code; it's a tool to help us, not catch us out in a lawyerly fashion. I will say that the article isn't a fantastic example, but at the same time it isn't too far off a more common idiom that is also UB as it is usually expressed - type punning. And type punning almost always works, except when it doesn't - http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/ http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al... [1] In particular, most programmers think pointers are simply numbers that represent memory addresses and that the chief distinguishing thing about null pointers is that accesses through them usually cause a memory page error owing to how the OS has mapped memory.

It was LLVM, not Clang. And it is a really great idea to treat UB as "it never happened". Just do not rely on UB and always use static analysis.

by sklogic 11y ago

It was LLVM, not Clang. And it is a really great idea to treat UB as "it never happened". Just do not rely on UB and always use static analysis.

Kristine1975 11y ago

And turn on the Undefined Behavior Sanitizer (http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) with -fsanitize=undefined It would have caught this bug at run-time.

pjmlp 11y ago

If it was that easy. CppCon 2015, Herb Sutter's talk about writing safe code in C++14, just check how many in the audience use such tools. https://www.youtube.com/watch?v=hEx5DNLWGgA&feature=youtu.be&t=2053 https://www.youtube.com/watch?v=hEx5DNLWGgA&feature=youtu.be... A tiny 1%, this on the conference of with many of the top C++ developers. Now imagine how little they get used on the typical enterprise environment, specially worse with C, that lacks many of the C++ added safety layers.

barrkel 11y ago

Most C and C++ programmers' mental models of the machine is different to the abstract machine in the respective specifications. [1] There's a genuine problem here of overly clever optimizers wilfully misreading code to produce fast, wrong code. But the compiler exists to map our ideas into code; it's a tool to help us, not catch us out in a lawyerly fashion. I will say that the article isn't a fantastic example, but at the same time it isn't too far off a more common idiom that is also UB as it is usually expressed - type punning. And type punning almost always works, except when it doesn't - http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/ http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al... [1] In particular, most programmers think pointers are simply numbers that represent memory addresses and that the chief distinguishing thing about null pointers is that accesses through them usually cause a memory page error owing to how the OS has mapped memory.