I appreciate that "totally_safe_transmute" carries some connotation that this is not a "safe" transmute, but rather a suspiciously specific denial.
Also possible to do directly in the "safe" type system, without messing around with /proc/mem: <a href="https://zyedidia.github.io/blog/posts/5-safe-transmute/" rel="nofollow">https://zyedidia.github.io/blog/posts/5-safe-transmute/</a>
Why don't the safe file I/O operations panic when /proc/self/mem is opened for writing?
I understand why they don't want to make all of File I/O unsafe just for edge cases like this, but shouldn't this be handled at runtime?
This is cute, but I hope it never turns up in any real codebase!<p>There’s an updated version with Windows support and better performance: <a href="https://github.com/John2143/totally-speedy-transmute/">https://github.com/John2143/totally-speedy-transmute/</a><p>What worries me is this macro, which “smuggles” the unsafe keyword past the forbid(unsafe_code) flag: <a href="https://github.com/John2143/totally-speedy-transmute/blob/master/safe/src/lib.rs">https://github.com/John2143/totally-speedy-transmute/blob/ma...</a><p>In my mind, this kind of capability makes Rust crate safety scanning and associated metadata worthless as currently implemented.<p>Package management tools ought to store code instead of binaries, and perform safety checks to via <i>instrumented compilers</i>.
This is a really weird hack to say the least. More like a flex showing that the author can implement transmute without unsafe than something you’d really use.
/proc/self/mem is the moral equivalent of `unsafe`. Of course you can do arbitrary things with it. Why would anyone be surprised? You could use <a href="https://man7.org/linux/man-pages/man2/process_vm_readv.2.html" rel="nofollow">https://man7.org/linux/man-pages/man2/process_vm_readv.2.htm...</a>. You could fork and ptrace. You can do any number of weird things.<p>Every day that goes by is a day I think we should make a beeline to CHERI even when we have "safe" languages.
C doesn't provide any reinterpretation operator, and the C++ one's name is a misnomer.<p>Casts are <i>conversion</i>: a new value is produced based on an existing one.<p>Reinterpretation requires a value to be in memory, and to be accessed using an lvalue of a different type. Most situations of this kind are undefined behavior.