|
|
Subscribe / Log in / New account

Debian, Rust, and librsvg

Debian, Rust, and librsvg

Posted Nov 16, 2018 10:44 UTC (Fri) by Ieee754 (guest, #128655)
In reply to: Debian, Rust, and librsvg by ballombe
Parent article: Debian, Rust, and librsvg

> 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, ...).


to post comments

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"


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds