new lint: pointer created from transmuting an int into a pointer is not able to be dereferenced

[timrobertsdev]

What it does

Points out potential UB when transmuting an integer into a pointer.

As of Rust 1.78, LLVM is informed that this is UB. In <= 1.77 this works, and the change caught me off guard, as an int->ptr conversion happens a lot when dealing with win32.

Advantage

The original code will cause UB if the pointer is dereferenced. The recommended code works as intended.

Drawbacks

Possible false positives, though I'm not sure of the use case.

Example

// win32 tends to hand out isize and wants you to use them as pointers
let l_param: isize = ...; 
let evt: *mut MSLLHOOKSTRUCT = std::mem::transmute(l_param);

Could be written as:

let l_param: isize = ...;
let evt = l_param as *mut MSLLHOOKSTRUCT;

[Alexendoo]

Do you know where/how this became UB?

There is https://rust-lang.github.io/rust-clippy/master/index.html#/transmutes_expressible_as_ptr_casts but it doesn't seem to catch it currently, we could fix that and raise it to a correctness lint

[timrobertsdev]

from the transmute docs: "Transmuting integers to pointers is a largely unspecified operation. It is likely not equivalent to an as cast. Doing non-zero-sized memory accesses with a pointer constructed this way is currently considered undefined behavior."

https://doc.rust-lang.org/std/mem/fn.transmute.html

I was informed via Zulip that this is reported to LLVM as UB as of Rust 1.78.

edit: link to the zulip topic https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/.E2.9C.94.20Function.20miscompilation.20with.20rustc.201.2E78.20and.20--release

[Alexendoo]

Great, thanks!

The LLVM change is probably rust-lang/rust#121282