Stream: t-lang/wg-unsafe-code-guidelines

Topic: static pointers


Elichai Turkel (Jan 09 2020 at 13:21, on Zulip):

Hi,
why is static A: *const u8 = &5; not allowed but static A: &u8 = &5; is?
also, why is a non mut static pointer "not thread safe"? it's read only memory into a static variable. it should be pretty defined.

Elichai Turkel (Jan 09 2020 at 14:11, on Zulip):

I think I understand.
static A: &u8 = &5; is a reference so there's a promise there cannot safely be a &mut T here. but *const T doesn't have such promise

gnzlbg (Jan 09 2020 at 14:58, on Zulip):

you can't go from a *const T to a &mut T in safe code

gnzlbg (Jan 09 2020 at 14:59, on Zulip):

IIRC there is an issue about implementing Send and Sync for raw pointers in the rfc repo

RalfJ (Jan 15 2020 at 12:03, on Zulip):

@Elichai Turkel the technical answer is that statics must be Sync, and raw pointers are not

gnzlbg (Jan 15 2020 at 13:27, on Zulip):

@RalfJ the unanswered part of the question is why aren't raw pointers Sync, where the current answer is probably "because that would be a footgun"

gnzlbg (Jan 15 2020 at 13:28, on Zulip):

this protection is not strictly necessary, since to trigger undefined UB one still needs to use unsafe code to read/write through these pointers.

gnzlbg (Jan 15 2020 at 13:29, on Zulip):

and there one is already proving that there are no data-races

RalfJ (Jan 15 2020 at 16:19, on Zulip):

indeed, raw pointers are non-Sync mostly as a lint... and because a struct containing raw pointers probably has some sufficiently interesting stuff going on that users should explicitly acknowledge thread-safety with unsafe impl Send/Sync

RalfJ (Jan 15 2020 at 16:20, on Zulip):

(also they can't opt-out by themselves as impl !Send/Sync is unstable)

RalfJ (Jan 15 2020 at 16:21, on Zulip):

for statics that a bit silly, but then what is the use-case for a static const ptr anyway?

gnzlbg (Jan 15 2020 at 16:24, on Zulip):

for statics that a bit silly, but then what is the use-case for a static const ptr anyway

mapping a static to a dynamic array?

gnzlbg (Jan 15 2020 at 16:24, on Zulip):

e.g. the linker puts a size at a symbol, and the array content at another symbol

gnzlbg (Jan 15 2020 at 16:25, on Zulip):

so you end up with:

extern {
    static ARRAY_SIZE: usize;
    static ARRAY: *const u8;
}
gnzlbg (Jan 15 2020 at 16:26, on Zulip):

You can't make ARRAY an array cause you don't know the length within your Rust program, You can't make it a reference cause maybe the size is 0 (and other issues)

gnzlbg (Jan 15 2020 at 16:26, on Zulip):

You also can't make it a slice

RalfJ (Jan 15 2020 at 18:39, on Zulip):

ah... interesting. doesnt match the OP, but still a good answer.

Elichai Turkel (Jan 16 2020 at 13:33, on Zulip):

for statics that a bit silly, but then what is the use-case for a static const ptr anyway?

My use case is passing that to FFI, by default it uses an extern static for a pointer, I wanted to replace that in fuzzing with a null pointer

RalfJ (Jan 16 2020 at 17:47, on Zulip):

I dont know what "using an extern static for a pointer" means

gnzlbg (Jan 17 2020 at 12:36, on Zulip):

@Elichai Turkel if FFI uses a raw pointer, you should use a raw pointer as well

gnzlbg (Jan 17 2020 at 12:36, on Zulip):

If you want to access that from multiple threads, then you should make sure that this is safe, and provide an abstraction (using unsafe code) that does that.

Elichai Turkel (Jan 18 2020 at 11:09, on Zulip):

@gnzlbg well the only reason I opened this is because my FFI uses raw pointer but rust doesn't allow me to define a raw pointer static myself.

gnzlbg (Jan 18 2020 at 11:10, on Zulip):

@Elichai Turkel I'd expect extern { static Foo: UnsafeCell<*const c_int>; } to just work

gnzlbg (Jan 18 2020 at 11:11, on Zulip):

but yeah, because raw pointers aren't Sync, you can't use bare raw pointers

gnzlbg (Jan 18 2020 at 11:11, on Zulip):

alternatively you can have a #[repr(transparent)] struct Wrapper(*const c_int); that implements Sync.

Elichai Turkel (Jan 18 2020 at 11:12, on Zulip):

:/ that sucks. Too bad we can't override this with unsafe somehow. But I guess that's the language :)

Last update: Jul 03 2020 at 17:50UTC