SoylentNews is people
SoylentNews
from the for-all-you-code-writing-types-out-there dept.
John Regehr, Professor of Computer Science, University of Utah, writes:
Undefined behavior (UB) in C and C++ is a clear and present danger to developers, especially when they are writing code that will execute near a trust boundary. A less well-known kind of undefined behavior exists in the intermediate representation (IR) for most optimizing, ahead-of-time compilers. For example, LLVM IR has undef and poison in addition to true explodes-in-your-face C-style UB. When people become aware of this, a typical reaction is: "Ugh, why? LLVM IR is just as bad as C!" This piece explains why that is not the correct reaction.
Undefined behavior is the result of a design decision: the refusal to systematically trap program errors at one particular level of a system. The responsibility for avoiding these errors is delegated to a higher level of abstraction. For example, it is obvious that a safe programming language can be compiled to machine code, and it is also obvious that the unsafety of machine code in no way compromises the high-level guarantees made by the language implementation. Swift and Rust are compiled to LLVM IR; some of their safety guarantees are enforced by dynamic checks in the emitted code, other guarantees are made through type checking and have no representation at the LLVM level. Either way, UB at the LLVM level is not a problem for, and cannot be detected by, code in the safe subsets of Swift and Rust. Even C can be used safely if some tool in the development environment ensures that it will not execute UB. The L4.verified project does exactly this.
(Score: 2) by tibman on Thursday February 16 2017, @04:48PM
Just looking at it there seems to be an assumption that undefined values == undefined behavior when that is not the case. The compiler is preventing undefined behavior by introducing undefined values and non-signaling NaNs. I guess that is the point of what they are saying? But equating the two seems wrong to me. Permitting undefined behavior is still unsafe. Like throwing @ signs around bugs in PHP or try/catches around random errors in java/c#. All kinds of side-effects and dealing with the resulting UB is not fun. Relying on the compiler to fix undefined behavior seems like a bad idea? If you overflow a number then it should blow-up in your face and not invent some "safe" value to continue. Seems like an area where there are a lot of opinions though.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by meustrus on Thursday February 16 2017, @05:04PM
I thought the same thing looking at `undef`, but when it gets to `poison` that's where undefined behavior comes in. It's still not the "external undefined behavior" we are supposed to avoid, however.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?