This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.

Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&editio...

I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860

Yes, that's an existing soundness hole in the compiler. You won't accidentally code it up yourself though.

If the bar is "deliberately malicious code results in a segfault", get back to me when they fix

  memcpy(0x10000, 0x20000, 0x10);

EDIT: and even that's being charitable; the Rust issue is viewed as a compiler bug which should be fixed.

The unsound bug tracker is were my heart gets all warm and fuzzy in Rust land.

All the ways to coerce and poke the implementation of what should be safe constructs to produce unexpected garbage - and people spending time fixing the issues!

It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.”

https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...

I think referencing the well-known cases in cve-rs[1] is quite a bad faith effort. Of course if you try reeeally hard to write unsound code, you can write unsound code. An edge case in the type system downstream of lifetime variance rules is simply not something that matters in any practical attempt to write safe software. I find the tracker interesting since it probes the boundary of the compiler, but it says absolute nothing to the effect of "Rust is unsafe".

[1] https://github.com/Speykious/cve-rs