External Publication
Visit Post

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

Rust Internals [Unofficial] March 7, 2026
Source

You might have a chance of adding new variants of a few functions in the ptr module (e.g. read, write or copy_non_overlapping) which allow null without volatile semantics. Since these couldn't easily be provided by third party crates and wouldn't impact the language at large.

You could then implement your own abstractions on top of these in a third-party crate to make these use-cases easier and safer.

But I don't see your higher impact proposals, like allowing ordinary pointers to dereference null or new reference types in core happening.


I think adding read_memory and write_memory to core::ptr like this should be enough:

pub const unsafe fn read_memory<T>(src: *const T) -> T;
pub const unsafe fn write_memory<T>(dst: *mut T, src: T);

Their semantics would be similar to those of volatile, but without the elision/reordering guarantees. Something similar to this:

When a memory operation is used for memory inside an allocation, it behaves exactly like read / write.

Memory operations, however, may also be used to access memory that is outside of any Rust allocation. In this use-case, the pointer does not have to be valid for reads/writes. Here, any address value is possible, including 0 and usize::MAX, so long as the semantics of such a read/write match those of ordinary memory access on the target hardware. The provenance of the pointer is irrelevant, and it can be created with without_provenance. The access must not trap.

(I'm sure the semantics as written above don't quite work. But they should give the right idea. Somebody with a better understanding of the rust memory model than me would need to specify this)

  • Unlike *_volatile or inline asm, these could be const, though they'd still need to panic when operating outside an allocation at compile-time.
  • copy, copy_nonoverlapping, replace, etc. can easily be implemented on top of these in a these in a third-party crate

Discussion in the ATmosphere

Loading comments...