Repository navigation
Creating a raw pointer to an external static requires an unsafe block #74843
Description
I tried this code (playground):
#![feature(raw_ref_op)]
extern {
static FOO: u32;
}
mod foo {
#[no_mangle]
static FOO: u32 = 5;
}
fn main() {
dbg!(core::ptr::addr_of!(FOO));
dbg!(&raw const FOO);
}I expected to see this happen: it compile and print the address of FOO twice.
Instead, this happened: compilation failed because accessing FOO requires an unsafe block
error[E0133]: use of extern static is unsafe and requires unsafe function or block
--> src/main.rs:13:10
|
13 | dbg!(core::ptr::addr_of!(FOO));
| ^^^^^^^^^^^^^^^^^^^^^^^^ use of extern static
|
= note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior
= note: this error originates in the macro `core::ptr::addr_of` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0133]: use of extern static is unsafe and requires unsafe function or block
--> src/main.rs:14:10
|
14 | dbg!(&raw const FOO);
| ^^^^^^^^^^^^^^ use of extern static
|
= note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior
As far as I can tell none of the potential causes of UB can be caused by just creating a raw pointer to the static. This should be a safe operation, and only when attempting to use the pointer in the future should you need to prove validity of it.
Activity
Nemo157 commentedon Jul 28, 2020
Based on the MIR generated this is creating a temporary reference to the static, asserting its validity, so technically does need
unsafewith the current desugaring.RalfJung commentedon Jul 29, 2020
Yeah I think this is a duplicate of #74840.
Basically the bug is that
&raw const FOOdesugars to&raw const *&FOO. That explains both problems.RalfJung commentedon Aug 17, 2020
Closing in favor of #74840.
Nemo157 commentedon Jul 20, 2023
I was reminded about this again today. #74840 got closed by banning
extern static FOO: !;, not by changing how creating a raw pointer to it is treated, so this was not affected. #77096 I think covers the high-level "statics need to be fixed", but it doesn't directly mention this case. So I think it's worth having this re-opened as something that should be fixed. (I'll update the code in the OP for the new stable API).RalfJung commentedon Jul 21, 2023
FWIW, creating a raw pointer to a mutable static is also unsafe. So this looks deliberate to me. Not saying it can't be changed, but that should be considered a change/feature, not a bugfix (i.e. it will need T-lang FCP at least).