RFC 1467: volatile

libs (raw-pointers | volatile)

Summary

Stabilize the volatile_load and volatile_store intrinsics as ptr::read_volatile and ptr::write_volatile.

Motivation

This is necessary to allow volatile access to memory-mapping I/O in stable code. Currently this is only possible using unstable intrinsics, or by abusing a bug in the load and store functions on atomic types which gives them volatile semantics (rust-lang/rust#30962).

Detailed design

ptr::read_volatile and ptr::write_volatile will work the same way as ptr::read and ptr::write respectively, except that the memory access will be done with volatile semantics. The semantics of a volatile access are already pretty well defined by the C standard and by LLVM. In documentation we can refer to http://llvm.org/docs/LangRef.html#volatile-memory-accesses.

Drawbacks

None.

Alternatives

We could also stabilize the volatile_set_memory, volatile_copy_memory and volatile_copy_nonoverlapping_memory intrinsics as ptr::write_bytes_volatile, ptr::copy_volatile and ptr::copy_nonoverlapping_volatile, but these are not as widely used and are not available in C.

Unresolved questions

None.