Stream: t-compiler/const-eval

Topic: Dangling pointers in enum discriminants


RalfJ (Nov 12 2018 at 09:54, on Zulip):

@Oli So I wrote https://github.com/RalfJung/rust/commit/71badfdc94586c66f0c5bb570401a74b356c06e7 because I realized (a) these assertions in read_discriminant can actually be violated (I have an example of an ICE here), and (b) this is yet another place where we made the wrong assumption that pointer values are never 0. Only in-bounds pointers are never 0. Unfortunately, fixing the latter leads to a build error in libstd...

error[E0080]: it is undefined behavior to use this value============>  ] 28/29: std
   --> libstd/sys_common/thread_local.rs:254:5
    |
254 |     static DTORS: StaticKey = StaticKey::new(Some(run_dtors));
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered a pointer at .dtor, but expected a valid enum discriminant
    |
    = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rust compiler repository if you believe it should not be considered undefined behavior
RalfJ (Nov 12 2018 at 09:55, on Zulip):

ah, this is a pointer to a function

RalfJ (Nov 12 2018 at 09:55, on Zulip):

check_bounds_ptr should probably accept those at offset 0

RalfJ (Nov 12 2018 at 10:23, on Zulip):

Submitted as https://github.com/rust-lang/rust/pull/55894

oli (Nov 12 2018 at 10:31, on Zulip):

looks good to me

oli (Nov 12 2018 at 10:32, on Zulip):

no need to address the missing test in this PR, so r=me with or without the test

Last update: Nov 15 2019 at 20:50UTC