Idea / Pre-RFC: Null-free pointer and Zeroable reference

H4n_uL:

You simply can never declare ∀x, ¬P(x) by closing your eyes and plugging your ears in front of ∃x, P(x).

Nobody is saying such systems do not exist; please do not suggest that's what's happening here.

Choosing to design a system that's willing to allocate memory at address 0 (not MMIO or special system structures, arbitrary allocated objects) is a choice, and one whose alternative is "sacrifice one byte of memory ".

MMIO or special system structures are potentially hardcoded in hardware (e.g. the x86 real-mode interrupt vector); it's understandable that those can't be changed. Similarly, if there's a software system with a "well-known location" at 0 for one particular data structure , that might be a compatibility consideration for users of that software. Both of those are straightforwardly handled by read_volatile, or additional added primitives with the same semantic as read_volatile (e.g. an equivalent to copy_nonoverlapping), without making other parts of the system deal with that. That's the thing that wrappers such as a hypothetical AnywherePtr could make it more ergonomic and safer.

But something involving the allocation of arbitrary objects (whether dynamically or at link time) is a software design choice, and one that could be changed without necessarily breaking compatibility. Just reserve the byte or word at zero and don't use it for anything, so other software never encounters it. The one byte or wasted will easily be made up for many times over by optimizations this enables elsewhere.

I think we're reaching the point where this thread is staring to go in circles and hit diminishing returns. The underlying concern (there needs to be some way to deal with reading/writing memory at 0) has been taken seriously, and responded to at length with ways to do that, including ways to do it in safe code. The idea of adding more functions akin to read_volatile (e.g. if a copy_nonoverlapping_volatile is needed) is also potentially reasonable. And we've even talked about how upcoming language features could help bring that from "possible but clunky" to "somewhat more ergonomic".

The main parts that aren't getting traction, here, are the idea of making changes outside of self-contained specialized "deal with pointers that might be 0" primitives, and the idea of supporting systems where something like a global variable or an address returned by an allocator could be a "valid object whose address is 0", without it being known in advance which one specific special object lives at 0. Allowing that would mean you'd have an object you can't take references to, can't access normally, can't access fields of, can't take references to fields of, etc. That is something for which it continues to seem reasonable for us to say "no, fix the system to not do that, your linker/allocator should not do that".

A pile of evidence showing that people have built systems that behave that way is not the same as a pile of evidence showing that people have systems that had to be designed that way. Systems where bytes aren't 8 bits also existed, and we aren't going to support those, either.

If you want to make a specific concrete proposal for e.g. an additional primitive function alongside read_volatile, or something else simple and self-contained that's needed to build a safe abstraction, please do go ahead and make that proposal (e.g. via an ACP). If If you want a pervasive change to the language that adds a new kind of reference, or makes core/alloc/std functions that operate on &T usable with that, or a similar non-self-contained change, please take this as continued confirmation that that isn't going to happen, on the basis that we're willing to go from "not possible" to "possible" but not willing to inflict massive pain on the ecosystem to take this use case from "possible" to "completely ergonomic and feeling like you're operating on a normal system without this unusual property".