I have quite a lot of MMIO in an embedded project, defined and used like this:
const REGISTER: *mut u32 = 0xDEADBEEF as *mut u32;
unsafe fn func() {
*REGISTER = 1;
}(see a playground link)
When I cargo build, I'm getting a whole host of warnings of the type:
warning: attempting to modify a `const` item
--> src/lib.rs:3:5
|
3 | *REGISTER = 1;
| ^^^^^^^^^^^^^
|
= note: `#[warn(const_item_mutation)]` on by default
= note: each usage of a `const` item creates a new temporary - the original `const` item will not be modified
note: `const` item defined here
--> src/lib.rs:1:1
|
1 | const REGISTER: *mut u32 = 0xDEADBEEF as *mut u32;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I expect no warnings, because I'm not assigning to a const, I'm assigning to a dereferenced *mut u32, aka a mutable u32.
I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is const, but it's pointing to a mutable u32. Dereferencing shouldn't care whether the pointer variable is const.
Meta
rustc --version --verbose:
rustc 1.46.0 (04488afe3 2020-08-24)
binary: rustc
commit-hash: 04488afe34512aa4c33566eb16d8c912a3ae04f9
commit-date: 2020-08-24
host: x86_64-unknown-linux-gnu
release: 1.46.0
LLVM version: 10.0
No backtrace for this bug; it's a warning.
I have quite a lot of MMIO in an embedded project, defined and used like this:
(see a playground link)
When I
cargo build, I'm getting a whole host of warnings of the type:I expect no warnings, because I'm not assigning to a
const, I'm assigning to a dereferenced*mut u32, aka a mutable u32.I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is
const, but it's pointing to amutableu32. Dereferencing shouldn't care whether the pointer variable isconst.Meta
rustc --version --verbose:No backtrace for this bug; it's a warning.