Windows: Prevent pointer provenance "optimization"

[jrose-signal]

On Windows, we can't just use extern symbols for our "start" and "end" pointers; we have to define them within the module. The current implementation uses a zero-length array for that. However, the compiler can track uses of that pointer through the creation of the distributed slice, and will optimize out accesses that are "out of bounds". Pass the pointer through core::mem::black_box to prevent this.

Potentially a fix for #67, which has similar symptoms. Our project likewise failed under LTO and passed normally, but this test change fails for me without the fix even with LTO turned off.

[dtolnay]

Thank you! Nice find.

[dtolnay]

Published in linkme 0.3.16.

[nvzqz]

I'm very concerned about this change with regard to the documentation of black_box. Sure this change works today, but it's not a guarantee.

Programs cannot rely on black_box for correctness, beyond it behaving as the identity function

[jrose-signal]

Yeah, that's a fair point. I don't know of a 100% formally correct way to do this operation in current Rust (stable or nightly), because it involves taking an address (from a reference) and using it to construct a pointer with different provenance. (Even if the START addresses referred to non-zero-sized values, you'd still have this problem.) I tried spelling that start as usize as *const T and it did not fix the problem, and the nightly-only strict_provenance APIs don't formally help either because we are deliberately violating strict provenance based on external information (the linker behavior).

One of us could bring this up on users.rust-lang.org, perhaps. Still, black_box cannot make things any worse than they were before.