project-safe-transmute VS totally-safe-transmute

Project "safe transmute"

In this case a simple From implementation or anything like that won't be different, even performance wise. For more complex cases there's project-safe-transmute, but that will still require you to annotate your structs in such a way that their layouts will be guaranteed to be compatible, which you're not currently doing.

You might also be interested in the project safe transmute, which might bring safe transmutes like these to stdlib in the future.

That's probably a job for the safe transmute project

One of the biggest notable examples is unsafe transmutes that could be safe. In fact there's a safe transmute working group trying to cover these cases. Just to give an example, if you have a #[repr(transparent)] newtype, it could be possible to safely transmute from a reference of an inner type to the type it wraps (for e.g. 1-tuple or 1-field structs), but doing that now presently requires unsafe.

Jokes aside, there is actually a work on going for making a subset of transmutes safe: https://github.com/rust-lang/project-safe-transmute

For example, there is this (pure safe Rust) code: https://github.com/ben0x539/totally-safe-transmute/blob/main... which accesses external resources (/proc/self/mem) in order to violate the safety guarantees.

The first is the totally_safe_transmute crate. I mean, who wouldn't love library code that has .expect("welp") and .expect("oof") as its error handling? But that's not even the really scary part. Issue #2 ("i hate this") remains open to this day, but for obvious reasons there's no chance of resolution. This post has some context and a line-by-line explanation of how it works.

You mean like this?

You can also do that in rust on linux: https://github.com/ben0x539/totally-safe-transmute/blob/master/src/lib.rs

I want to correct this statement: Rust can be safer, but not if a library you use contains unsound code. Unsoundness is most often caused by unsafe code, but not always (totally_safe_transmute, anyone?). There is a misconception that unsafe code blocks are always unsound and should be avoided at all costs, but they're completely fine if the safety contracts are upheld. In fact, unsafe blocks isolate the potential issues to make it easier to identify where undefined behavior may be occurring. unsafe code blocks are a feature of the language, and their usage should not be viewed as opting out of any safety the language provides, imo.

Just reimplement totally_safe_transmute in Zig. No need for unsafe.

Why transmute() when you can totally_safe_transmute()?

Well, there is always the totally-safe-transmute.

They should use https://github.com/ben0x539/totally-safe-transmute