@ -19,11 +19,11 @@ boggling.
* Transmute has an overloaded return type. If you do not specify the return type
* Transmute has an overloaded return type. If you do not specify the return type
it may produce a surprising type to satisfy inference.
it may produce a surprising type to satisfy inference.
* Transmuting an `&` to `&mut` is UB. While certain usages may *appear* safe,
* Transmuting an `&` to `&mut` is Undefined Behavior . While certain usages may
note that the Rust optimizer is free to assume that a shared reference won't
*appear* safe, note that the Rust optimizer is free to assume that a shared
change through its lifetime and thus such transmutation will run afoul of those
reference won't change through its lifetime and thus such transmutation will
assumptions. So:
run afoul of those assumptions. So:
* Transmuting an `&` to `&mut` is *always* UB.
* Transmuting an `&` to `&mut` is *always* Undefined Behavior .
* No you can't do it.
* No you can't do it.
* No you're not special.
* No you're not special.
@ -32,8 +32,8 @@ boggling.
* When transmuting between different compound types, you have to make sure they
* When transmuting between different compound types, you have to make sure they
are laid out the same way! If layouts differ, the wrong fields are going to
are laid out the same way! If layouts differ, the wrong fields are going to
get filled with the wrong data, which will make you unhappy and can also be UB
get filled with the wrong data, which will make you unhappy and can also be
(see above).
Undefined Behavior (see above).
So how do you know if the layouts are the same? For `repr(C)` types and
So how do you know if the layouts are the same? For `repr(C)` types and
`repr(transparent)` types, layout is precisely defined. But for your
`repr(transparent)` types, layout is precisely defined. But for your