{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihm2vgsfm6p2yevymy5ajy5nvwlgvij6ml5wponufpisrxgujldtu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgscrfq2p4t2"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=6#post_120",
  "publishedAt": "2026-03-11T15:02:28.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "(click for more details)"
  ],
  "textContent": "Thank you for coming by and confirming the volatile path - I appreciate it, and I'm glad your bootloader case is resolved.\n\nYour case was a single `u32` read, which `read_volatile` covers well. But the patterns that arise on the same hardware family get harder quickly:\n\n  * A struct placed at 0x0 by firmware: you need `&mut DevTreeBlob` to call methods, mutate fields, pass to APIs expecting references - `read_volatile` cannot construct that.\n  * A slice starting at 0x0: `from_raw_parts` constructs `&[T]`, which is instant UB.\n  * Bulk operations: `ptr::copy` across a region that includes 0x0 - currently UB.\n\nDetailed patterns here (click for more details)\n\nThese are not exotic patterns; they're the bread and butter of bare-metal firmware on Cortex-M. And the hardware you work with - the VA108xx/VA416xx family - is currently operational on the ISS (STP-H5), STPSat-5, STPSat-6, and Astranis DemoSat-2. Future software on these platforms may need exactly these patterns.\n\nWould any of these arise in your work, or in work you've seen at IRS?",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}