To clarify why undefined behavior is really bad in practice: if LLVM ever detects that your code performs undefined behavior according to the standard, it is *designed* to take full advantage of that fact when making optimizations. In other words, all hell will break lose, in potentially very complicated and subtle ways.
Geoffrey On Sep 7, 2013, at 1:22 PM, Daniel Micay <[email protected]> wrote: > On Sat, Sep 7, 2013 at 4:15 PM, Oren Ben-Kiki <[email protected]> wrote: > I miss-spoke; when I said "machine" I meant "platform" (combination of HW and > SW). Is unintentionally dereferencing a null pointer a silent error on any > existing platform? > > Yes, it's only a segmentation fault in userland code on platforms where the > kernel is set up to make the lowest page read-only. Rust still needs to be > memory safe in a kernel. > > But isn't a very good question either. A better one would be: Would it be > _useful_ to define `steal` and use it in programs, such that it triggers a > null pointer dereference (undefined behavior and all) if someone tries to > access the hole? This is a softer question and I suspect the answer is "yes" > - at least until a better way to safely update structures in-place is found... > > It would be undefined behaviour, so it wouldn't be useful. Rust is a memory > safe language and can't allow safe code to generate LLVM IR invoking > undefined behaviour. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
