3 ms·
Because they define-away the scenarios where UB is an issue for most code. Sometimes they do this by having a GC, but Rust and Swift prove that isn't necessary.
by xenadu02 8y ago
Because they define-away the scenarios where UB is an issue for most code. Sometimes they do this by having a GC, but Rust and Swift prove that isn't necessary.
Such languages typically do provide some form of "no promises, here there be dragons" in the form of unsafe blocks or functions. Restricting this region of unsafety is a huge benefit for programmers and compilers. Programmers because relatively few pieces of code need to be carefully reviewed. Compilers because most of the program contains little or no UB.
As a typical example, in C you can alias and type pun. Therefore to avoid all UB the compiler would need to be extremely careful in any function containing a pointer. You could return a reference to a local through a separate opaque function call, or receive multiple pointers all aliasing the same memory. To completely avoid all UB means inserting checks after every potentially mutable machine instruction, or emitting duplicate function bodies that take different paths when the pointers alias; that's assuming the compiler even has enough type information to answer the question!
With typical C#, Rust, Swift, etc you just can't cause those kinds of problems without deliberate subterfuge and use of Unsafe types or blocks.
- pjmlp 8y agoLanguages like Ada and Modula-2 were already proving it long time ago. Or to go even further in the past, NEWP, still alive on Unisys ClearPath mainframes.
- eddyb 8y agoNote that `unsafe` code blocks (or having some unsafe primitives) fundamentally results in some kind of UB in the language as a whole, and you totally can create tons of problems from it, since the rest of the language has invariants it can't itself violate, but the unsafe code can (potentially much easier than C, if there are more invariants) - that is the "UB", and the invariants that can be violated are what the compiler optimizes based on. Lest we forget, any language with a C FFI capability must have some notion of UB, because the FFI effectively includes the C code in its own semantics (unless fully sandboxed, which may be too expensive to be done).
- pjmlp 8y agoTrue, but they are quite easy to track down. In systems like Unisys ClearPath, you can even configure the system such that only admins can execute applications with unsafe blocks. In C any line of code, if care is not taken to use the correct compiler flags, can be a possible source of UB.
- eddyb 8y agoIndeed. Only wanted to point out that their optimizations also rely on UB, so they're bad examples for specifically "optimizing without relying on UB".
- umanwizard 8y ago> In C any line of code, if care is not taken to use the correct compiler flags, can be a possible source of UB. What do you mean?
- pjmlp 8y agoYou need to turn on all warnings as errors, static analysers and pedantic modes depending how each compiler allows them. ANSI C11 has 200 documented cases of UB, and each compiler might have additional cases, are you sure you can know all of them by heart while looking at a random line of C code?