I'm developing for a single-core embedded chip. In C & C++ it's common to statically-define mutable values that can be used globally. The Rust equivalent is roughly this:

```rust
static mut MY_VALUE: usize = 0;

pub fn set_value(val: usize) {
    unsafe { MY_VALUE = val }
}

pub fn get_value() -> usize {
    unsafe { MY_VALUE }
}

```

Now anywhere can call the free functions `get_value` and `set_value`.

I *think* that this should be entirely safe in single-threaded embedded Rust, but I've not been able to find a definitive answer. I'm only interested in types that don't require allocation or destruction (like the primitive in the example here).

The only gotcha I can see is with the compiler or processor reordering accesses in unexpected ways (which could be solves using the volatile access methods), but is that `unsafe` *per se*?

---

Edit:

[The book](https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#accessing-or-modifying-a-mutable-static-variable) suggests that this is safe so long as we can guarantee no multi-threaded data races (obviously the case here)

> 
> With mutable data that is globally accessible, it’s difficult to ensure there are no data races, which is why Rust considers mutable static variables to be unsafe.
> 
> 
> 

[The docs](https://doc.rust-lang.org/std/keyword.static.html#mutable-statics) are phrased less definitively, suggesting that data races are only one way this can be unsafe but not expanding on other examples

> 
> accessing mutable statics can cause undefined behavior in a number of ways, for example due to data races in a multithreaded context
> 
> 
> 

[The nomicon](https://doc.rust-lang.org/nomicon/what-unsafe-does.html) suggests that this should be safe so long as you don't somehow dereference a bad pointer.