[lint idea] dangerous transmutes

[durka]

Along the lines of useless_transmute, it seems plausible to warn on transmute::<X, Y>(x) where X and Y aren't both primitive types or marked #[repr(C)], since as @ubsan keeps reminding us this is likely to cause UB.

[strega-nil]

@durka heh :)

The only valid transmutes of a repr(Rust) struct that I know of are in std::repr, so it should(?) be fairly simple to special case those.

[Ryman]

I would love to see something like this, it's very easy to forget about and have seen it come up a number of times.

[durka]

@ubsan I expect running clippy on libstd would trigger more lints than that :)

[oli-obk]

also casting a #[repr(C)] struct with padding to anything where the padding becomes accessible is UB

[durka]

Does clippy have access to ask rustc whether a struct has any padding, or
would the logic have to be duplicated?

On Thu, May 12, 2016 at 11:15 AM, Oliver Schneider <notifications@github.com

wrote:

also casting a #[repr(C)] struct with padding to anything where the
padding becomes accessible is UB

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Manishearth/rust-clippy/issues/546#issuecomment-218789297

[oli-obk]

clippy can ask rustc, at least miri can do it (since a few weeks ago), so clippy should be able to do it, too.

[felix91gr]

Upon inspection, I believe this issue is still relevant:

1. The Rustonomicon states that layouts are only known to be the same if both types are either both repr(C) or both repr(transparent).
2. The last attempt at a lint for this was @Jarcho's work, which is now in Nursery due to known issues which have been investigated and documented at Thoroughly investigate transmute_undefined_repr #8496.

It might not be a good-first-issue though. Maybe E-hard?