6 ms·

But does it carry the Rusty guarantees?

• cryptonector 1y ago
  Why wouldn't it?
  • pornel 1y ago
    It could fail if the generated C code triggered Undefined Behavior. For example, signed overflow is UB in C, but defined in Rust. Generated code can't simply use the + operator. C has type-based alias analysis that makes some type casts illegal. Rust handles alias analysis through borrowing, so it's more forgiving about type casts. Rust has an UnsafeCell wrapper type for hacks that break the safe memory model and would be UB otherwise. C doesn't have such thing, so only uses of UnsafeCell that are already allowed by C are safe.
    • FractalFir 1y ago
      I have workarounds for all "simple" cases of UB in C(this is partially what the talk is about). The test code is running with `-fsantize=undefined`, and triggers no UB checks. There are also escape hatches for strict aliasing in the C standard - mainly using memcpy for all memory operations.
    • bregma 1y ago
      Wait until you find out how unsafe software written in the machine language that Rust usually transpiles to is.
      • adwn 1y ago
        That's not the same, and not what pornel is talking about. The x86 ADD instruction has a well-defined behavior on overflow, and i32 + i32 in Rust will usually be translated to an ADD instruction, same as int + int in C. But a C compiler is allowed to assume that a signed addition operation will never overflow (the dreaded Undefined Behavior), while a Rust compiler must not make that assumption. This means that i32 + i32 must not be translated to int + int. For example, a C compiler is allowed to optimize the expression a+1<a to false (if a is signed), but a Rust compiler isn't allowed to do this.
    • cryptonector 1y ago
      > It could fail if the generated C code triggered Undefined Behavior. > For example, signed overflow is UB in C, but defined in Rust. Generated code can't simply use the + operator. Obviously, yes, but it could generate overflow checks.
• GolDDranks 1y ago
  If the transpilation itself is bug-free, why not? For static guarantees, provided we transpile Rust code that already compiles on a normal Rust compiler, the guarantees are already checked and there, and the dynamic ones such as bounds checking can be implemented runtime in C with no problems.
  • chii 1y ago
    this assumes the rusty guarantees are transitive. There's no reason to believe it isn't, but it'd be nice to see some sort of proof, or at least an argument for it.
    • josephg 1y ago
      Should be. The rust borrow checker has no runtime component. It checks the code as-is before (or during) compilation. Arguably it’s not the compiled binary that’s “safe”. It’s the code.
      • kreetx 1y ago
        Borrow checker, and more generally any type checkers, are essentially terminating programs ran during compilation process, thus safety guarantees given by them are ensured before the code is transformed into some target language.
        • olivermuty 1y ago
          Thats assuming lossless transpilation though
          • carlmr 1y ago
            That's a problem for almost every language, not just Rust. C++ also compiles to intermediate representations, and then to machine code. Errors happen on that path. Rust just get rid of a lot of errors that could have been in the original specification (the source code).