Supporting Rust is inevitable for platforms that want to remain viable for modern software releases

Posted Nov 22, 2024 18:22 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: Supporting Rust is inevitable for platforms that want to remain viable for modern software releases by daroc
Parent article: NonStop discussion around adding Rust to Git

It's not clear to me whether mrustc is suitable, today, for compiling code that is not rustc (and is also separately compiled with a more normal Rust toolchain, so at least we know it's valid and we don't have to emit "good" error messages). The README seems unsure on this point.

As for whether it's "dumb" enough - all I really want is something that is maintained. If they're going to continue maintaining mrustc, and explicitly support using it to transpile non-rustc code, then that would be fine regardless of whether it is "dumb" or "smart." But if, for whatever reason, mrustc turns out not to be suitable, then it seems plausible that it would be easier to write and maintain a "dumb" transpiler than a "smart" transpiler.

mrustc compatible with Rust 1.54

Posted Nov 24, 2024 2:38 UTC (Sun) by gmatht (guest, #58961) [Link] (2 responses)

Well, it compiled my pet project "ZeroSum Accounts Reconciliation Tool" fine: https://www.dansted.org/zerosum/

The transpiled code wasn't exactly concise, but it worked. The transpiled code can make some assumptions about the target architecture so you might have to fiddle mrustc if you want to target something exotic. Also, mrustc seems to assume that you will compile the resulting code with -fwrapv (otherwise implementation defined signed integer overflow in Rust will become undefined in the resulting C).

I imagine the main limitation of mrustc is that it only supports up to Rust 1.54 at the moment. So, this excludes Rust-for-Linux which requires at least 1.78.0.

mrustc compatible with Rust 1.54

Posted Nov 24, 2024 15:43 UTC (Sun) by ralfj (subscriber, #172874) [Link] (1 responses)

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."