31–40 of 99 posts
Have you tried Diverse Double-Compiling (DDC) to test if the official rust compiler has a backdoor? Use crustc to compile the rust source code, producing a new compiler. Then use this new compiler and the official rustc binary, both with deterministic flags, to compile the rust source code again. The two outputs should match bit for bit.
This reminds me of https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
> I put my left hand in a blender. The blender won. (Still have all my fingers, just some stitches). I will not elaborate further. What a shame. I would've read an article about this.
Have you tried Diverse Double-Compiling (DDC) to test if the official rust compiler has a backdoor? Use crustc to compile the rust source code, producing a new compiler. Then use this new compiler and the official rustc binary, both with deterministic flags, to compile the rust source code again. The two outputs should match bit for bit.
Have you tried Diverse Double-Compiling (DDC) to test if the official rust compiler has a backdoor? Use crustc to compile the rust source code, producing a new compiler. Then use this new compiler and the official rustc binary, both with deterministic flags, to compile the rust source code again. The two outputs should match bit for bit.
This reminds me of https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
[1] https://github.com/tsoding/crust [2] https://github.com/bext-lang/b [3] https://www.nokia.com/bell-labs/about/dennis-m-ritchie/kbman...
There are relatively few people who understand Rust’s compiler internals, LLVM backends, and obscure target support deeply. But there are many engineers who understand C compilers, ABIs, linkers, makefiles, cross-compilation, old operating systems, and weird platform-specific compiler behavior.
If Rust can be lowered into target-specific C, then some problems stop being exclusively “Rust compiler problems” and also become C toolchain problems. That means more people can inspect the generated C, build failures, linker errors, ABI mismatches, and compiler-specific behavior.
C is obviously not a magic portability layer. ABI details, integer widths, alignment, TLS, aliasing, and undefined behavior still matter. But as an ecosystem boundary, C gives many more engineers a way to participate in debugging and porting work.
I think that social/maintenance aspect may be more important than the language translation itself.
> For the past 3 years, I have been working on compiling Rust to C. .. This is, by my count, the 14th attempt: cilly Gotta respect the dedication to a niche interest. > The primary goal of this is support for old/obscure hardware with no LLVM/GCC support. I remember reading about the bootstrapping question, how it typically requires a Rust compiler to build the Rust compiler from source. https://bootstrapping.mirahez…
So the author made a Rust to C transpiler and immediately used it to transpile... the Rust compiler. I love it.
But it doesn't mean rustc generates code for that target, only that you can run it there. You'd still have to teach LLVM about the target. Although that might already have been done.
It's not that useful for retro computers because the Rust compiler needs too much memory for most machines of the 32-bit era.
The most interesting part of this to me is not “Rust to C” by itself, but the fact that it widens the pool of people who can help debug portability problems. There are relatively few people who understand Rust’s compiler internals, LLVM backends, and obscure target support deeply. But there are many engineers who understand C compilers, ABIs, linkers, makefiles, cross-compilation, old operating systems, and weird pla…
> Don't post generated text or AI-edited text. HN is for conversation between humans.