{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigxsy7jxu6jth7mfxyhk7734xi3rntnn2d2elszcclcymaqnch4ua",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgted4getrs2"
  },
  "path": "/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991?page=7#post_124",
  "publishedAt": "2026-03-11T20:52:41.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "bytemuck/src/zeroable_in_option.rs at main · Lokathor/bytemuck · GitHub"
  ],
  "textContent": "EDIT: Disregard, I noticed after posting that you meant code relying on `*core::ptr::null()` being UB, not the memory representation of references.\n\nH4n_uL:\n\n> Does any existing code actually use \"0x0 is UB, therefore unreachable\" as part of its soundness proof?\n\n~~Yes,`bytemuck` uses it for its `ZeroableInOption` trait, to allow safely zero-initializing structs which contain e.g. `Option<&u32>`. If 0x0 becomes a legal pointer, then `Option<&u32>` needs to overflow its discriminant to the another word and the all-zeros representation may no longer be valid (on my machine with latest rust, all-zeros is `None` for `Option<usize>`, but that's not a stable guarantee). Source code if you want to check it out:~~ bytemuck/src/zeroable_in_option.rs at main · Lokathor/bytemuck · GitHub\n\n~~I'm sure there are other uses in popular public crates, but this was the first one that came to mind, in a library I've used as a dependency several times. I have a bunch of Rust code which instantly becomes unsound (and may or may not UB depending on how rustc lays out`repr(Rust)` values) if that change happens.~~",
  "title": "Idea / Pre-RFC: Null-free pointer and Zeroable reference"
}