{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibzr5kn3q5tf62a2rbglxrlfhn26psebrflv3iag6ksffiu3g26qy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgsq6zr5tb52"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=7#post_122",
  "publishedAt": "2026-03-11T16:24:03.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Idea / Pre-RFC: Null-free pointer and Zeroable reference - #115 by Vorpal"
  ],
  "textContent": "H4n_uL:\n\n> These 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>\n> Would any of these arise in your work, or in work you've seen at IRS?\n\nI can only speak for this processor family, because I specifically had to write a bootloader for it. I can not speak for other architectures. The program memory is not touched anymore after the program has booted. 0x0 is the start of the program memory. Only code is stored here. No structure will be placed here, and for the copy operation, I am happy with the current solution of just using a volatile read for 4 bytes, and then using regular slice bulk operations for the rest. Right now, I don't see any reason why the regular application would want to read from or write to address 0x0 again after the program has booted.\n\nI agree to what Vorpal said: Idea / Pre-RFC: Null-free pointer and Zeroable reference - #115 by Vorpal . Use volatile reads for MMIO or to read byte/word at 0x0, and while it might not be possible to use it as regular RAM, losing 1 - 4 bytes of address space is not that big of a deal.",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}