On Tue, Jan 14, 2014 at 3:16 PM, Tobias Müller <[email protected]> wrote: > Lee Braiden <[email protected]> wrote: >> On 14/01/14 01:50, Palmer Cox wrote: >> >> On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> Daniel Micay <[email protected] >> <mailto:[email protected]>> wrote: >> > Do you know what undefined behavior is? It doesn't mean unspecified. >> >> True, but despite beeing so often cited it won't format your hard disk >> (even in C). >> >> Actually, it's possible, at least on systems without MMU protection --- >> some embedded systems, for example. Ints are often used (not just in >> your own code but in library code) to index a jump table. If that index >> is a different number than you expected it to be, you could end up >> executing calling random "functions" in memory. Said "functions" could >> (and probably would) crash within 1--2 instructions, but even then, it's >> not INCONCEIVABLE that those instructions could equate to "1) load hard >> drive device number into the first arg register; 2) call the OS >> format_drive function". > > But this is just as likely with wrapping integers. _Any_ deviation from the > expected behavior is as dangerous as UB.
That's not how undefined behaviour works in LLVM (and C). If you perform an integer arithmetic operation with undefined behaviour, it does not mean that you get an undefined result back. Undefined values and undefined behaviour are not the same thing. An arithmetic operation in LLVM can be marked as undefined on overflow with `nsw` or `nuw` rather than wrapping. `clang` uses `nsw` on signed integers when `-fwrapv` is not passed to communicate this guarantee. LLVM can then assume that signed integers never overflow, enabling more optimizations. It can become aware that makes loops must terminate, and even gain the ability to count the number of iterations. It can also glean information on the possible ranges of values based on the invariants provided by most arithmetic operations. If it sees `x + INT_MAX`, then `x` is less than or equal to zero. Invoking undefined behaviour is always a safety issue. You would need to look at the assembly for the whole program in detail to know whether an optimization pass made an assumption that's not going to hold. This will of course change across every compiler version, which is why C programs so often break with a new `gcc` release. Wrapping on overflow is a logic error and in rare cases may become a safety issue if it's then used in a specific kind of `unsafe` code. The `unsafe` code needs to make the assumption that the integer is in some valid range, without checking it. > And that's just why I want to help the programmer with those checks as much > as possible. Lifetimes and non-nullable pointers do a great job ensuring > this for memory management, int overflow is missing such a feature. Rust has support for big integers. It also has support for library-defined overflow checks via the LLVM overflow checking intrinsics. A language feature is not necessary to support this. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
