Comment by uecker
Yes, you also do not want to do random casts, but this is even easier. I do not get your point out memory validity in Rust. What if you write where a pointer is stored, or even a boolean?
Yes, you also do not want to do random casts, but this is even easier. I do not get your point out memory validity in Rust. What if you write where a pointer is stored, or even a boolean?
I did take a look at the projects which attempt to address conversion of C to Rust and even if article talk about about uplifting C to idiomatic Rust, or to utilize decompilation techniques, I do not see anything of that in any existing project.
- C2Rust: https://github.com/immunant/c2rust From what I see, very limited testing of what C can be uplifted. - Citrus: https://gitlab.com/citrus-rs/citrus Overall almost no tests. I would not even mention this project, since it seems to be working on hope. https://gitlab.com/citrus-rs/citrus/-/tree/master/tests?ref_... - Corrode: https://github.com/jameysharp/corrode Written in Haskel, not in Rust as others, have potential, since they utilize csmith for testing.But still lack of testing. https://github.com/jameysharp/corrode/tree/master/scripts
I really don't see any project which attempt to reverse engineer Rust idioms from C, even if in limited contexts. Maybe the goal of the article to inspire all of us. Or Maybe I miss some other existings projects?
C2Rust is the largest project here, it was born out of corrode. The general idea of it is to do a direct C -> unsafe Rust port, and then also provide tooling to convert unsafe Rust -> safe Rust, as a secondary tool to be used as a second step. I don't think they've shipped much of that second tool yet, but I haven't checked in in a while.
That’s a related concept but not the same thing.
The “validity” rules in Rust (like C’s trap representations) are about which bit patterns represent valid values, not about which pointer types may alias the same memory.
Strict aliasing is a type-based access rule; validity is a value-based representation rule.
Rust enforces the latter (invalid values are undefined behavior), but explicitly does not enforce the former (raw pointers may alias arbitrarily). That’s the difference.
To put it into code:
float foo(const uint32_t *xs) {
const float *fp = (const float*)xs; // UB: incompatible effective type
fn foo(xs: *const u32) {
let ptr = xs as *const f32; // not UB to access through ptr later
It’s also true you must pay attention to validity: this works in Rust because all bit patterns of u32 and f32 are valid for f32 (IEEE-754). If you tried u32 -> bool, you’d hit UB not because of aliasing, but because many u8 patterns are invalid for bool (only 0 and 1 are valid). Creating the pointer is fine; dereferencing would only be okay if you first ensure at runtime that the stored bits are valid for the target type, and alignment is satisfied.
I'm talking about type punning specifically here. There's a lot of old C code out there that stores everything in int * buffers and casts pointers back to the correct type. I'm even aware of one toolchain for a widely used MCU that typedef'd char to int (i16).
I believe this would be legal in Rust today if you respected the other rules, with the caveat that it wouldn't be remotely idiomatic or possible without unsafe.