mrustc compatible with Rust 1.54

Posted Nov 24, 2024 15:43 UTC (Sun) by ralfj (subscriber, #172874)
In reply to: mrustc compatible with Rust 1.54 by gmatht
Parent article: NonStop discussion around adding Rust to Git

One difficulty with transpiling Rust to C is that there is plenty of well-defined Rust code (even plenty of safe Rust code) around raw pointers that is Undefined Behavior in C. It's quite hard to compile Rust to standards-compliant C. It would be a lot easier to compile Rust to a dialect of C that removes a lot of the UB (no strict aliasing [this one has a flag in many compilers, but the rest of this list does not], no UB on out-of-bounds pointer arithmetic, no pointer-lifetime-end-zap -- this list is not exhaustive), but C compilers would first have to gain support for such a dialect.

I don't actually know what current Rust-to-C transpilers do in these cases. I assume they just generate C code with UB and hope for the best...

mrustc compatible with Rust 1.54

Posted Nov 26, 2024 5:18 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

Cast to intptr_t and hope for the best (i.e. hope that the arch is kind enough to give you a working intptr_t, and is not CHERI or CHERI-like). Or, if you're trying to support arches with no intptr_t, cast (a pointer to the pointer) to char*, and treat it as a string of raw bytes.

Yes, you lose provenance. No, that is not UB under any version of C that I've ever heard of. The standard explicitly provides that we are allowed to round-trip through at least char*, and intptr_t if it exists. If that breaks provenance, oh well, your implementation is just expected to deal with it anyway.

There probably is a performance cost to doing this. But IMHO it's acceptable if the alternative is "I can't run this code at all."