{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreida5rjegwb25o3io76ppehqtshpcagmkj2idd4my5bemqbnmw3dtu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgkqi762jqg2"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=6#post_112",
  "publishedAt": "2026-03-08T12:55:09.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "rust#138351",
    "Rust's 2018 roadmap | Rust Blog",
    "Announcing the Embedded Devices Working Group",
    "literally embedded in satellites (Astranis DemoSat-2, TechEdSat-8 CubeSat)"
  ],
  "textContent": "Your `read_memory` / `write_memory` proposal in #93 was genuinely helpful and I appreciated it. However, under Phase I, `ptr::read` / `ptr::write` themselves would become valid at 0x0 which means the separate functions would be redundant rather than complementary. This isn't a rejection of your idea; it's that the two approaches solve the same layer differently, and if Phase I lands, the existing APIs already cover what `read_memory` was designed to do.\n\nCodesInChaos:\n\n> The \"soundness issue\" is that I'm using a dummy implementation for the new `core::ptr` functions I proposed.\n\n\n    // library/core/src/ptr/mod.rs:1546-1569\n    pub const unsafe fn replace<T>(dst: *mut T, src: T) -> T {\n            // ...\n            mem::replace(&mut *dst, src)\n        }\n    }\n\n\nUhh... I think we have a divergence here - I meant that `core` itself relies on non-zero reference internally, which was the root of rust#138351. I didn't meant your dummy impl, sorry about the misunderstanding.\n\nCodesInChaos:\n\n> It is an excessive solution, since the benefits are so small. The use-cases you address are extremely rare, and already have usable workarounds today. And in the end, Rust doesn't have to be usable for every single application.\n\nTo be clear: The Rust Core Team explicitly stated that embedded devices (which are no_std) are one of 4 important domains and stated to make it a first-class target.\n\n  * Rust's 2018 roadmap | Rust Blog\n  * Announcing the Embedded Devices Working Group\n\n\n\nAnd the environments in question are not edge-cases, they're the highest-stakes subset. The Vorago VA108xx in the OP is a radiation-hardened MCU literally embedded in satellites (Astranis DemoSat-2, TechEdSat-8 CubeSat), and the workaround it was forced into (inline assembly) is a direct violation of safety standards.\n\nAnyway, I don't think we disagree on as much as it might seem - your `read_memory` / `write_memory` proposal came from recognising the same gap and I think your proposal stands on its own merit even if my RFC never lands. Where we differ is on scope, and I think that's better resolved through discussion in a formal RFC than here. I'd welcome your contribution there.",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}