{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiao5ij2debseyc3yhilkoc72pkblo7geb4qiqkx4j6pc7snn37t7u",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlrmagnsmbl2"
  },
  "path": "/t/include-racy-reads-in-rust-memory-model-with-maybeinvalid-t/24289#post_17",
  "publishedAt": "2026-05-13T22:59:51.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "josh:\n\n> I feel like we're definitely talking past each other at this point. People do implement seqlocks in C, and they're used regularly in production systems, including the Linux kernel.\n\nLinux defines its own memory model and is intended to be built only with compilers that are capable of implementing it if given the right command-line options. As such, it isn't written in standard C (and won't work on arbitrary C compilers – it was originally intended just to work on gcc, but I think clang also now implements the same model). Seqlocks work in Linux's memory model, but the model itself may not be precisely defined (especially because I think program correctness is determined using a case-by-case \"ensure that the source code compiles into machine code that does what we want on every platform we support\" rather than being defined in terms of an abstract machine).\n\nThe dialect of C used for Linux deviates from standard C in other ways too (e.g. in standard C, dereferencing NULL is undefined behaviour; IIRC, in Linux's variant, the only possible behaviours of dereferencing NULL are 1. to run the hardware instruction for accessing address 0 (which usually causes a processor trap) or 2. (if the value that would be read is never used) to do nothing). The primary motivation behind this sort of thing is to reduce the potential security consequences of accidental undefined behaviour.",
  "title": "Include racy reads in Rust memory model with `MaybeInvalid<T>`"
}