{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibapiolval2tpffnse663xx7xha3bfrzwihuwddjrkuwl4acxaeji",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfukbamsynk2"
  },
  "path": "/t/impact-of-static-variables-on-api-soundness/24039#post_4",
  "publishedAt": "2026-02-26T23:16:23.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Also, instead of marking your current API functions as `unsafe`, what you can do is mark whatever new functions you add that could break the invariants as `unsafe`, e.g.:\n\n\n    static ORIGINAL: u32 = 0;\n    static PTR: AtomicPtr<u32> = AtomicPtr::new(&raw const ORIGINAL as *mut u32);\n\n    pub fn existing_function() -> u32 {\n        // Safety: PTR is known to contain a valid pointer and we used Acquire/Release correctly\n        unsafe {\n            *PTR.load(Ordering::Acquire)\n        }\n    }\n\n    /// Safety: you must not pass in an invalid `v`\n    pub unsafe fn new_function(v: *const u32) {\n        PTR.store(v as *mut u32, Ordering::Release);\n    }\n",
  "title": "Impact of Static Variables on API Soundness"
}