From dc4e0267f0d36b6e1b948f7200d74171a1bcdf45 Mon Sep 17 00:00:00 2001 From: onestacked Date: Sun, 9 Jul 2023 18:31:40 +0200 Subject: [PATCH] Document soundness of Integer -> Pointer -> Integer conversions in ` const` contexts. see this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Soundness.20of.20Integer.20-.3E.20Pointer.20-.3E.20Integer.20conversions) --- library/core/src/intrinsics.rs | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/library/core/src/intrinsics.rs b/library/core/src/intrinsics.rs index d042aaf3084d6..509a8b63743c5 100644 --- a/library/core/src/intrinsics.rs +++ b/library/core/src/intrinsics.rs @@ -1130,7 +1130,10 @@ extern "rust-intrinsic" { /// may lead to unexpected and unstable compilation results. This makes `transmute` **incredibly /// unsafe**. `transmute` should be the absolute last resort. /// - /// Transmuting pointers to integers in a `const` context is [undefined behavior][ub]. + /// Transmuting pointers *to* integers in a `const` context is [undefined behavior][ub], + /// unless the pointer was originally created *from* an integer. + /// (That includes this function specifically, integer-to-pointer casts, and helpers like [`invalid`][crate::ptr::invalid], + /// but also semantically-equivalent conversions such as punning through `repr(C)` union fields.) /// Any attempt to use the resulting value for integer operations will abort const-evaluation. /// (And even outside `const`, such transmutation is touching on many unspecified aspects of the /// Rust memory model and should be avoided. See below for alternatives.)