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?
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... On Sat, Sep 7, 2013 at 7:20 PM, Daniel Micay <[email protected]> wrote: > On Sat, Sep 7, 2013 at 12:09 PM, Oren Ben-Kiki <[email protected]> wrote: > >> If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...) >> every null pointer will fault (which I strongly hope will...), then I'd be >> quite happy in saying formally that accessing a hole leads to "undefined >> behavior" and make good use of knowledge that any such access will, in >> fact, fault, on any machine I might be coding to today. >> > > You get a segmentation fault on Linux because the first page is marked > read-only for userland processes. It's valid on almost any hardware to > dereference a pointer equal to zero, which is how LLVM defines the null > pointer. However, LLVM explicitly considers a dereference of the null > pointer to be undefined behaviour so it doesn't matter how it could or > couldn't be implemented in hardware. >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
