31–40 of 41 posts
C doesn't provide any reinterpretation operator, and the C++ one's name is a misnomer. Casts are conversion : a new value is produced based on an existing one. 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.
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.
The point is likely to show that Rust's "safety" is not absolute and it's possible to do lots of silly stuff with "safe" code.
I appreciate that "totally_safe_transmute" carries some connotation that this is not a "safe" transmute, but rather a suspiciously specific denial.
Earlier quoted context omitted.
> You can always smuggle unsafe past the compiler, it can't stop you even in principle. The linked updated library uses a different method: it literally smuggles the "unsafe" keyword past the safety checks by removing the space character from "un safe". This can and should be caught by the compiler -- it has full access the syntax tree at every intermediate stage of compilation! Instead, the Cargo tool and the rustc…
> The linked updated library uses a different method: it literally smuggles the "unsafe" keyword past the safety checks by removing the space character from "un safe". > This can and should be caught by the compiler -- it has full access the syntax tree at every intermediate stage of compilation! Instead, the Cargo tool and the rustc compiler are simply keyword-searching for the literal string "unsafe", and are hence…
/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 https://man7.org/linux/man-pages/man2/process_vm_readv.2.htm... . You could fork and ptrace. You can do any number of weird things. Every day that goes by is a day I think we should make a beeline to CHERI even when we have "safe" languages.
Earlier quoted context omitted.
double transmute_int_to_double(int x) { double result = 0; memcpy(&result, &x, sizeof(int) is not a UB, and it doesn't even necessarily touch any memory: transmute_int_to_double: movd xmm0, edi ret [0] https://godbolt.org/z/czM3eh8er
> is not UB Not by my interpretation of n3096 (April 2023 ISO C draft). > doesn't even necessarily touch any memory The abstract semantics calls for memory being touched. Data flows that go through memory in the abstract semantics can be optimized not to go through memory. UB can do anything at all.
What clause(s) support the claim that that example is UB? At least at first glance it looks pretty similar to the sometimes-recommended way to perform safe type-punning in C, and the only way to "directly" invoke UB via memcpy (passing pointers to overlapping objects) isn't relevant here.
The only suspicious part to me is the size/number of bytes to copy, but I'm not sure that's outright UB?
Earlier quoted context omitted.
It’s not just /proc/sys/mem. One could also modify executable files and cause all manner of other mayhem. At the end of they, if you have access to all ambient privileges available to your process, you can use them. Trying to specifically block memory safety violations would be a bit odd.
> One could also modify executable files ETXTBSY.
Earlier quoted context omitted.
> is not UB Not by my interpretation of n3096 (April 2023 ISO C draft). > doesn't even necessarily touch any memory The abstract semantics calls for memory being touched. Data flows that go through memory in the abstract semantics can be optimized not to go through memory. UB can do anything at all.
> Not by my interpretation of n3096 (April 2023 ISO C draft). What clause(s) support the claim that that example is UB? At least at first glance it looks pretty similar to the sometimes-recommended way to perform safe type-punning in C, and the only way to "directly" invoke UB via memcpy (passing pointers to overlapping objects) isn't relevant here. The only suspicious part to me is the size/number of bytes to copy,…
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 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.
The point is likely to show that Rust's "safety" is not absolute and it's possible to do lots of silly stuff with "safe" code.