Debian, Rust, and librsvg

Posted Nov 14, 2018 10:51 UTC (Wed) by ballombe (subscriber, #9523)
In reply to: Debian, Rust, and librsvg by glaubitz
Parent article: Debian, Rust, and librsvg

Agreed. If rust has the option to generate C code, even slower and with lesser security property than the LLVM backend, this would still be useful for porting and bootstrapping.

Debian, Rust, and librsvg

Posted Nov 14, 2018 11:15 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (2 responses)

Given that Rust can target WASM it is really a pity that there is no option to generate plain C. Then there would be no problem with LLVM usage as that can be run on a supported platform and the final C will be compiled with GCC to the target.

Debian, Rust, and librsvg

Posted Nov 14, 2018 11:21 UTC (Wed) by glaubitz (subscriber, #96452) [Link] (1 responses)

Maybe this project can be used for that: https://github.com/SimonJF/cmm_of_wasm :-)

There is mrustc which could be interesting, too: https://github.com/thepowersgang/mrustc

Debian, Rust, and librsvg

Posted Nov 14, 2018 12:30 UTC (Wed) by nix (subscriber, #2304) [Link]

That's not generating C, though: it's not even generating OCaml: it's generating the OCaml IR so it can reuse its code generator, and generating native code. I don't really see that this is much of an improvement over using LLVM as far as portability to weird obscure arches goes. (It's still a really nifty piece of work, though!)

Debian, Rust, and librsvg

Posted Nov 14, 2018 12:49 UTC (Wed) by lobachevsky (subscriber, #121871) [Link]

There is also the mrustc project https://github.com/thepowersgang/mrustc

Debian, Rust, and librsvg

Posted Nov 15, 2018 14:58 UTC (Thu) by ptman (subscriber, #57271) [Link]

IIRC Rust used to be able to target C, but that code hasn't seen maintenance once rust became good at self-hosting

Debian, Rust, and librsvg

Posted Nov 16, 2018 10:44 UTC (Fri) by Ieee754 (guest, #128655) [Link] (4 responses)

> If rust has the option to generate C code,

This is just wishful thinking. Rust is not C, that is, not all Rust can be 1:1 mapped to C. A lot of Rust is platform specific, so even if one could compile Rust to C, one would need a platform library abstracting syscalls, libc, compiler extensions, etc. wrapping the C systems APIs way beyond what libc offers.

Unless a big company pays 100 people to work on this full-time for a couple of years, this won't become production ready enough such that hobbyist can start modifying the parts required for the resulting C to even compile in the less supported platforms.

If you only want to target x86_64 linux with glibc, then this is doable, and some projects already try to do this. For anything else, there is a titanic amount of work required.

Just as an example, C has macros to support many platforms, Rust does so too. Imagine translating C with macros to Rust: you would have to first generate C without macros for each platform, then generate Rust code, and then recombine all that to generate
"portable Rust". The process from Rust to C isn't very different. Now think about all the nasty things that platform specific C code can use (pragmas, linking, ...).

Debian, Rust, and librsvg

Posted Nov 16, 2018 22:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> This is just wishful thinking. Rust is not C, that is, not all Rust can be 1:1 mapped to C.
The intention is to use C as the target language, instead of LLVM. This is actually quite doable, but the generated C will look more like assembly rather than a high-level program.

Debian, Rust, and librsvg

Posted Nov 16, 2018 23:06 UTC (Fri) by apoelstra (subscriber, #75205) [Link] (2 responses)

> The intention is to use C as the target language, instead of LLVM. This is actually quite doable, but the generated C will look more like assembly rather than a high-level program.

I'm not sure what the best way to think about this is, as far as "trusting trust" goes. Is assembler-like C that much better than machine code in terms of making back doors visible?

Debian, Rust, and librsvg

Posted Nov 16, 2018 23:23 UTC (Fri) by sfeam (subscriber, #2841) [Link]

If I understand correctly, the concern is not with reading the output code. The concern is to build the compiler using a second compiler that has itself been judged to be free of trojans or other surreptitious additions.

Debian, Rust, and librsvg

Posted Feb 23, 2021 16:11 UTC (Tue) by immibis (subscriber, #105511) [Link]

The point isn't to make backdoors visible, so I don't see the relevance? The point is to support more CPU architectures.

The point of Rust isn't "security" as in "making backdoors visible" either, if that's where the confusion is coming from. The point of Rust is "security" as in "writing fewer exploitable bugs"