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

RalfJung:

But people will read documentation saying that actually accessing null pointers is fine, and then assume they are fine for crates that use the old terminology, and cause UB. This is a serious problem, it will cause UB bugs in real code.

I would take this concern seriously if it were backed by a concrete scenario. I made the same request in #83: if there is existing unsafe code whose soundness depends on the non-null assumption for raw pointers, I would appreciate a concrete example. (Does any existing code actually use "0x0 is UB, therefore unreachable" as part of its soundness proof?) This is not intended as pressure - I need concrete evidence to assess cost and risk.

RalfJung:

So the question is, can you demonstrate that the benefits outweigh this significant cost?

The benefits of this proposal are threefold:

1. Enabling normal pointer operations and language-level reference-like operations on addresses that are valid by hardware guarantee.
2. Enabling compliance with safety certification requirements without resorting to volatile access or inline assembly. A safety certification standard for Rust (e.g. MISRA-Rust) does not yet exist, but closing this gap now directly contributes to future specification efforts and Rust's adoption in safety-critical domains.
3. Structural elimination of the resulting audit risk.

On the cost side, the cost has been described in principle but not yet demonstrated in practice.

RalfJung:

Field projections provide everything you need to build a suitable abstraction in library code. The ergonomics aren't perfect, but easily good enough for a niche usecase such as this. We don't accept RFCs on the off-chance that other RFCs (with significant momentum behind them!) don't make it, so your talk about "weakest links" doesn't support your RFC either.

I understand that perspective, but as noted earlier, in mission-critical engineering, depending on unstable features is not permitted. Having sufficient momentum is not the same as being stabilised, and even if field projection does land, I do not see how that constitutes grounds for rejecting this RFC.

RalfJung:

What remains is your claim that the missed optimizations caused by volatile accesses matter.

RalfJung:

You have one example of code actually accessing address 0, and that code is apparently doing a big memcpy of some data from address 0x0 to non-volatile memory -- there's nothing to optimize here, a volatile memcpy will be just as fast as a regular one.

That example is the simplest possible case - a value-by-value read. The moment you need a struct reference, a slice, or a bulk copy at 0x0, read_volatile cannot help. In this domain, one is enough. One fails, everything fails. Moreover, I am the only one who has presented a real benchmark in this thread. I expect the same level of evidence for the claim that volatile memcpy is equally performant.

RalfJung:

The work-around is volatile accesses. There is no need for inline assembly. You keep making incorrect claims even after their incorrectness has been pointed out to you. This is tiring.

Acknowledged, I added volatile access alongside inline assembly in #112.

RalfJung:

Your OP also still talks about "reference construction" and "slice creation", despite it having been made unambiguously clear to you that those will never allow null.

The generalised examples in Need and significance are intended to demonstrate how the current AM breaks, not to claim that the code should become well-defined behaviour as written. Though, it could be misinterpreted so I added a disclaimer. Refer to Before reading section.