]> git.lizzy.rs Git - rust.git/commit - src/tools/miri
Rollup merge of #95547 - RalfJung:ptr-int-transmutes, r=scottmcm
authorDylan DPC <99973273+Dylan-DPC@users.noreply.github.com>
Tue, 5 Apr 2022 20:58:56 +0000 (22:58 +0200)
committerGitHub <noreply@github.com>
Tue, 5 Apr 2022 20:58:56 +0000 (22:58 +0200)
commite597d06144f356f58cf16a15ac7f21bc0d4d3628
treef8f6f6b58e219036edef778c0c9bdac65e6e34a3
parentc5e7e952925be74fc7dd6a2fac8e16df9e2044f6
parentdd85a7682cf17103ec72eb1606fabf04bbf52971
Rollup merge of #95547 - RalfJung:ptr-int-transmutes, r=scottmcm

caution against ptr-to-int transmutes

I don't know how strong of a statement we want to make here, but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`.

Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB, or they don't round-trip properly, or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed').

Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this.

Cc `@rust-lang/lang`
library/core/src/intrinsics.rs