Is the address of a local variable "allocated on the stack"?

[nikomatsakis]

Code sometimes has a need to get an address from the stack — often for debugging, but sometimes for other reasons. Consider this snippet of code from rayon-rs/rayon#571:

let base = 0;
let addr = &base as *const _ as u64;

the goal here is just to get "some stack pointer" to use as a (quite weak) seed for a PRNG. This feels... sketchy to me, I thought it was worth noting.

[RalfJung]

So what is the question here? Whether that's allowed? I mean, it's all safe code...

It's certainly nothing to rely on in a PRNG though.

[cuviper]

For the purpose of that PRNG, I don't care that it's weak, just that it's different between threads. I guess the concern in rayon-rs/rayon#571 (comment) is that this code could be transformed in such a way that all threads see the same address, which would defy my intent.

[RalfJung]

Oh yes you don't get any guarantees about this being useful for your purpose at all. This is true even in C, so I don't think we can get anything better out of LLVM. The actual integers you see are entirely implementation-defined.

[cuviper]

What would be a better way? Take the address of some TLS?

[cuviper]

I suppose for this weak case, I could just base it on the thread index.

[RalfJung]

I don't know of any way to do this in standard C. Integers obtained from pointers are useless except for the sole purpose of turning them back into a pointer.

Now, what compilers guarantee in practice is a whole different story. I haven't even seen that written down anywhere. Compilers certainly know less about TLS than about stack storage, so I'd venture a guess that as a higher chance of surviving the optimizer. But I am totally guessing here.

[RalfJung]

If you want a guaranteed unique thing and it's not in a critical loop (so accessing a shared cacheline is okay), I suggest some kind of static COUNTER: AtomicUsize = AtomicUsize::new(0), and then use the result of COUNTER.fetch_add(1, Ordering::Relaxed). I have no idea what fetch_add does on overflow though.

[cuviper]

This is only called once per thread, so such sharing would be fine. Thanks for the info -- I'll play with it and change that code to something independent of pointers.

[Amanieu]

Here's an example of a function which returns a thread-unique usize using the address of a TLS variable: https://github.com/Amanieu/parking_lot/blob/efd045412780f478202e775041d837b3f2186d1d/src/raw_remutex.rs#L14

Can any of the following asserts fail? If so, which ones?

let a = 0u32;
let b = 0u32;

let x = &a as *const u32 as *const u8;
let y = &b as *const u32 as *const u8;
assert_ne!(x, y);

let x = &a as *const u32 as usize;
let y = &b as *const u32 as usize;
assert_ne!(x, y);

If the answer is "yes", here's a follow-up question. Does turning a and b into UnsafeCell::new(0u32) change the answer?

I'm currently writing unsafe code in crossbeam-channel that assumes those asserts never fail. Basically, all I want to do is temporarily allocate a few variables on the stack or the heap (but preferrably on the stack) and then use their addresses as unique IDs. What's the best way of achieving that?

[RalfJung]

@stjepang I assume you meant let y = &b as ... in both cases?

[RalfJung]

In some really crazy world, maybe the Rust compiler will exploit the fact that these are all read-only references and hence they can all point to just 0... but that would require us to entirely give up pointer identity, which I deem unlikely.

Still, personally, I'd use

let x = &mut a as *const u32 as usize;
let y = &mut b as *const u32 as usize;
assert_ne!(x, y);

Integers are always less aggressive around such optimizations than pointers, and mutable references mean the identity matters. (Same for UnsafeCell but why would you prefer that?)

But, realistically, I don't think we can ever afford to break your asserts. I'm already worried about the fact that we break pointer identity for ZSTs.

@RalfJung Yes - sorry! I've corrected the typo now.

Thanks for clearing it up, this is reassuring since I got worried about UB for a moment. I'll just make sure to use mutable references then.

[nikomatsakis]

@RalfJung

So what is the question here? Whether that's allowed? I mean, it's all safe code...

The question -- which I think is relevant outside of the question of how rayon seeds its PRNG -- is whether we guarantee that addr points on the stack.