{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiewbnyxb2yexeaxtfi6gswz6h5blnrj3cmojogrsojymwqhkpftwe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mf3fab2gtli2"
  },
  "path": "/t/idea-pre-rfc-treat-0x0-as-a-valid-address-not-as-null/23991?page=4#post_72",
  "publishedAt": "2026-02-17T12:02:51.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "@H4n_uL",
    "[2]",
    "[3]",
    "docs.rs",
    "volatile - Rust",
    "docs.rs",
    "voladdress - Rust",
    "@phil_opp",
    "@Lokathor",
    "`VolatileRef<'lt>`",
    "↩︎",
    "↩︎",
    "↩︎"
  ],
  "textContent": "RalfJung:\n\n> I will also note that framing this as \"demands\" makes the entire thing sound needlessly confrontational\n\nA tangent on this topic: I imagine this is probably a non-native English problem. In French, for instance, the verb _demander_ is a \"false-ish friend\", as it means to _ask_ or to _request_[1].\n\nBut it's nonetheless good for you to have called out that the usage of that verb ought to be adjusted/edited (cc @H4n_uL, we understand you probably did not intend it as confrontational ).\n\n* * *\n\nH4n_uL:\n\n> 197g:\n>\n>> there be a **library** pointer (`NonNull` but with lifetime) that encapsulates at least the safety preconditions of `read_volatile` with which we have an alternative to represent values that start at address `0`.\n>\n> This is a much more practical path than what I originally proposed. A vocabulary type **in core** that builds on the existing `read_volatile` safety model without breaking changes to `&T` nor niche disruption, and the ecosystem adopts it at its own pace. I love it.\n\n  * (Emphases mine.)\n\n\n\nEver since I started reading the OP, this was my thought as well; it feels like the main culprit here is the following:\n\n###  Working with direct, raw, `volatile_{read,write}()`s is _unergonomic / impractical / unpleasant_.\n\nBut for such cases, there is always a solution for this, **one which need not involve _a language change_** : to define a convenience library abstraction (hence my first emphasis in that quote).\n\nFrom there, stems a second important question:\n\n#### Should such a library abstraction live in the standard library (notably: `::core`[2]), or could it just be a user-provided \"third-party\" library?\n\nGiven that the use case for null-supporting pointer operations remains, in the overall ecosystem of Rust usage so far, incredibly _niche_[3], I'd _personally_ vote for starting with the latter, and seeing how it goes from there.\n\nI'd like to point out, in this regard, that the following two crates exist:\n\ndocs.rs\n\n### volatile - Rust\n\nProvides volatile wrapper types for raw pointers.\n\ndocs.rs\n\n### voladdress - Rust\n\nA crate for working with volatile locations, particularly Memory Mapped IO (MMIO).\n\nSo we'd have to sort out:\n\n  * whether your ergonomic requirements are satisfied by one of these crates;\n  * or if they're not, _in which regard_? _Where_ could these crates be improved (cc @phil_opp, the author of the former, and @Lokathor, of the latter).\n    * Notably, `::voladdress` has no lifetimes in its types, and whilst `::volatile` does have a lifetime-infected wrapper, `VolatileRef<'lt>`, it uses a `ptr::NonNull`, so it won't be usable out-of-the-box for the OP's situation.\n\n\n\nYou may thus want to write (or _kindly ask_ that somebody else write for you) your own take on the matter. Whilst it may seem \"excessive\" —\"why does Rust not come pre-bundled with such a tool?\"—, I'd like to point out that the energy and time required for authoring such a thing is most likely _smaller_ than the overall energy and time spent in this whole very thread\n\n* * *\n\n  1. the translation of \"to demand\" in French then being _exiger_. ↩︎\n\n  2. hence my second emphasis ↩︎\n\n  3. heh ↩︎\n\n\n",
  "title": "Idea / Pre-RFC: Treat 0x0 as a valid address, not as null"
}