{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig7gsjasn7iripd3hjso7ubmu2suugub33omgq2vouqx4qghtmwyu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mghzagb23wo2"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=5#post_93",
  "publishedAt": "2026-03-07T08:40:52.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "allocation",
    "`read`",
    "valid",
    "`usize::MAX`",
    "`without_provenance`"
  ],
  "textContent": "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.\n\nYou could then implement your own abstractions on top of these in a third-party crate to make these use-cases easier and safer.\n\nBut I don't see your higher impact proposals, like allowing ordinary pointers to dereference `null` or new reference types in `core` happening.\n\n* * *\n\nI think adding `read_memory` and `write_memory` to `core::ptr` like this should be enough:\n\n\n    pub const unsafe fn read_memory<T>(src: *const T) -> T;\n    pub const unsafe fn write_memory<T>(dst: *mut T, src: T);\n\n\nTheir semantics would be similar to those of volatile, but without the elision/reordering guarantees. Something similar to this:\n\n> When a `memory` operation is used for memory inside an allocation, it behaves exactly like `read` / `write`.\n>\n> 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.\n\n(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)\n\n  * Unlike `*_volatile` or inline asm, these could be `const`, though they'd still need to panic when operating outside an allocation at compile-time.\n  * Other functions `copy`, `copy_non_overlapping`, `replace`, etc. can easily be implemented on top of these in a these in a third-party crate\n  * Maybe `copy` and `copy_non_overlapping` would have a performance benefit from an intrinsic, so perhaps adding them makes sense as well.\n\n",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}