{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifeqooup4bgasmzoqi3hcplp6gx3d32njwmcqnvrd7yo3nqqpmzbi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mh4fd6t42aq2"
  },
  "path": "/t/dereferenceable-zero/23991?page=7#post_132",
  "publishedAt": "2026-03-15T09:07:54.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "datasheet"
  ],
  "textContent": "In the type mapping section how do you make sure lifetimes are obeyed when mapping between the new `&T` and `*const T`?\n\nFor example it suggets mapping `fn(&T) -> &U` to `fn(*const T) -> *const U`. This is unsound.\n\n> **`opt-3` (speed-first)** Converts only at FFI (`repr(C)`, `extern \"C\"`) and `transmute` boundaries. All other `Option<&T>` remain as-is (2 words, no niche). Recommended for bare-metal / 0x0-access code where conversion overhead or inaccessibility is undesirable\n\nHow do you know which layout a `&Option<&T>` is? It can come from a field of either a `repr(rust)` or `repr(C)` struct. And I can create a `Vec<&Option<&T>>` with mixed layouts.\n\nWhere do you save the extra word of the `Option<&T>`. after all:\n\n> W65C02S: 16-bit address bus spanning the full 64 KiB address space (0x0000-0xFFFF). There is not a single byte to sacrifice as a sentinel. (datasheet, pp. 5, 15)",
  "title": "Dereferenceable Zero"
}