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 DannyB on Thursday February 16 2017, @08:15PM
List<President> presidents = . . . ;
for( final President president : presidents ) {
if( president.isAnIdiot() && president.getFaceColor().equals( Colors.ORANGE ) ) {
presidents.remove( president ); // make idiots un-presidented
}
}
Depending on the collection implementation, after the remove() call, the implicit iterator created by the for() may now be unable to continue traversing the collection.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by NCommander on Thursday February 16 2017, @10:14PM
Far too many languages let you do this and leave it to the runtime to decide to crash or not. As far as I know, Rust is the only language off the top my head that specifically checks if such an operation is safe at compile time, and dies with a compiler error if you would invalidate the iterator while you're in it.
Still always moving