Rust to C compiler – 95.9% test pass rate, odd platforms

https://fractalfir.github.io/generated_html/cg_clr_odd_platforms.html

by todsacerdoti • 1 year ago

253 255 1 year ago

fractalfir.github.io

claudiojulio• 1 year ago

Very cool. C to Rust would be fantastic.

ndndjdnd• 1 year ago

What benefit would you envision from this?

trentearl• 1 year ago

There is DARPA program called TRACTOR to pursue this:

https://www.darpa.mil/news/2024/memory-safety-vulnerabilitie...

IshKebab4• 1 year ago

1. It means you don't need C code & a C compiler in your project any more, which simplifies infrastructure. E.g. cross compiling is easier without any C.

2. You can do LTO between Rust and the C->Rust code so in theory you could get a smaller & faster executable.

3. In most cases it is the first step to a gradual rewrite in idiomatic Rust.

Aurornis3• 1 year ago

C to Rust would be fantastic.

This would have to go into one big unsafe block for any nontrivial program. C doesn’t convey all of the explicit things you need to know about the code to make it even compile in Rust.

JonChesterfield• 1 year ago

If your translator is correct, the rust front end enforces the semantics of rust then C implements them. It's as safe as any other implementation.

If that feels uncomfortable, consider that x64 machine code has no approximation to rust safety checks, and you trust rust binaries running on x64.

"Correct" is doing some heavy lifting here but generally people seem willing to believe that their toolchain is bug free.

CryZe2• 1 year ago

I once implemented a WASM to Rust compiler that due to WASM's safety compiles to fully safe Rust. So I was able to compile C -> WASM -> Rust and ended up with fully safe code. Though of course, just like in WASM, the C code is still able to corrupt its own linear memory, just can't escape the "sandbox". Firefox has employed a similar strategy: https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

fabrice_d• 1 year ago

See https://github.com/immunant/c2rust

g-mork• 1 year ago

Mark Russinovich recently gave a talk at a UK Rust conference that mentioned Microsoft's internal attempts at large scale C->Rust translation, https://www.youtube.com/watch?v=1VgptLwP588

pjmlp• 1 year ago

Note the AI part of the tooling.

jeroenhd3• 1 year ago

Tools like those exist. The problem with them is that they use unsafe blocks a lot, and the code usually isn't very idiomatic. Translating global variable state machines into more idiomatic Rust state machines based on things like named enums, for instance, would be very difficult.

With the help of powerful enough AI we might be able to get a tool like this, but as AI still very much sucks at actually doing what it's supposed to do, I don't think we're quite ready yet. I imagine you'd also need enough memory to keep the entire C and Rust code base inside of your context window, which would quickly require very expensive hardware once your code grows beyond a certain threshold. If you don't, you end up like many code assisting LLMs, generating code independently that's incompatible with itself.

Still, if you're looking to take a C project and extend it in Rust, or perhaps slowly rewrite it piece by piece, https://c2rust.com/ is ready for action.

Krutonium• 1 year ago

But does it carry the Rusty guarantees?

cryptonector2• 1 year ago

Why wouldn't it?

pornel2• 1 year 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.

GolDDranks• 1 year 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• 1 year 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.

db48x• 1 year ago

I'm not convinced that it’s worth spending any time supporting most proprietary systems. Maybe not even Windows, but especially the really expensive ones.

o11c• 1 year ago

You shouldn't spend your own effort; you should make it clear that you're open to users of such systems contributing.

That's how GCC became so dominant - there were people already using all sorts of Unixen and they wanted a compiler, so they made it work.

weinzierl• 1 year ago

That is absolutely true but exotic platforms are also fun to investigate and you can learn a lot. So I'd say you shouldn't spend your own effort if you don't want to but I am glad fractalfir did and I am looking forward to the his RustWeekNL presentation.

eru• 1 year ago

Of course, accepting contributions comes with some effort, too.

lmm8• 1 year ago

You shouldn't spend your own effort; you should make it clear that you're open to users of such systems contributing.

In practice you can't really draw a line between those two things.

I don't know the end result, but I remember a discussion of how implementing parts of Git in Rust would be a problem because NonStop, a currently supported platform, has no Rust support. Of course the sane response would be "screw NonStop then", but having accepted contributions to make NonStop a supported platform that isn't an easy path to take.

AlienRobot• 1 year ago

Funny, because the average person is convinced it's not worth spending any time supporting Linux!

EasyMark2• 1 year ago

I'm always convinced that people will pick up arbitrary projects that they are interested in and might not necessarily lead to a new pitch for venture capital or the next unicorn.

iaaan• 1 year ago

Lots of interesting use cases for this. First one that comes to mind is better interop with other languages, like Python.

xmodem2• 1 year ago

What does this gain you that you can't already do with `extern "c"` functions from rust?

nicce3• 1 year ago

’Extern c’ still uses Rust. You want to skip Rust and call C from other languages directly.

pornel2• 1 year ago

The interop is already great via PyO3, except when people want to build the Rust part from source, but are grumpy about having to install the Rust compiler.

This hack is a Rust compiler back-end. Backends get platform-specific instructions as an input, so non-trivial generated C code won't be portable. Users will need to either get pre-generated platform-specific source, or install the Rust compiler and this back-end to generate one themselves.

chrisrodrigue• 1 year ago

They are grumpy about having to install the Rust compiler for a good reason. You can’t compile for Rust on Windows without using MSVC via Visual Studio Build Tools, which has a restrictive license.

snvzz• 1 year ago

Excellent.

Now we can quickly re-rustify projects by converting them to C.

dilawar2• 1 year ago

Is it LLVM IR --> C? Or Rust AST to C?

dilawar2• 1 year ago

Found the answer in the project readme.

My representation of .NETs IR maps nicely to C, which means that I was able to add support for compiling Rust to C in 2-3K LOC. Almost all of the codebase is reused, with the C and .NET specific code only present in the very last stage of compilation

nickpsecurity6• 1 year ago

Which might also allow one to use tools that work on .NET bytecode. They include verification, optimization, debugging, and other transpilers. You might also get a grant or job offer from MS Research. :)

epage• 1 year ago

It is a rustc backend, ie an alternative to llvm, gcc, or the cranelift backends.

It started as a .NET backend but they found that their approach could easily support C code generation as well so they added that. They do this by turning what rustc gives them into their own IR.

OutOfHere• 1 year ago

How is this not dangerous? How can one be assured that all of the compile-time safety features of the Rust compiler are still in effect? Handwaving does not help.

HeliumHydride• 1 year ago

It's as safe as LLVM IR is safe, assuming you trust the LLVM IR -> C translation step.

grandempire• 1 year ago

Because they happen at compile time?

cv50052• 1 year ago

How does the rust compiler assure that when compiling to machine code? Machine code is less safe than C after all.

lmm8• 1 year ago

Machine code is generally much safer than C - e.g. it usually lacks undefined behaviour. If you're unsure about how a given piece of machine code behaves, it's usually sufficient to test it empirically.

wiseowise2• 1 year ago

How can one be assured that all of the compile-time safety features of Java are is still in effect in bytecode?

RossBencina• 1 year ago

The JVM class loader verifies the bytecode:

https://stackoverflow.com/questions/755005/how-does-bytecode...

flomo3• 1 year ago

Of course, everyone votes up the headlines, but this link seems like premature WIP. Hopefully this will get posted for real after the presentation.

ay2• 1 year ago

I clicked through to the project at https://github.com/FractalFir/rustc_codegen_clr - from a quick glance at it, with 1.8k stars and 17 contributors, it deserves a better treatment than a passive—aggressive dismissal like this as a top comment.

It is a very impressive piece of work.

flomo3• 1 year ago

Right, and that probably should have been the link rather than some in-process thoughts about popcount or w/e. Sorry for not figuring it out and clicking around effectively.

xmodem2• 1 year ago

Yeah, exactly. Here on a website called 'Hacker News', we're only interested in projects when they're feature complete and mature enough for production deployment, not before. (/s)

baq3• 1 year ago

This is Hacker News, not Product Hunt.

EasyMark2• 1 year ago

If you read the article you'll see this is a status report and not a pitch for a final product.

cod1r• 1 year ago

this fractalfir person is super talented. See them on the rust reddit all the time. I'm not knowledgeable on compilers at all but others seem to really like their work.

landr0id• 1 year ago

I think they’re pretty young too. Hoping for a bright future ahead of them!

jokoon• 1 year ago

At first I read it as C to rust compiler.

What is the point of compiling rust to C?

drdeca• 1 year ago

I think there are probably C compilers for more platforms than there are rust compilers. So, if you want to compile your rust project on some obscure platform that doesn’t have a rust compiler for it yet, you could compile to C and then compile the resulting C code for that platform?

Just a guess.

p0w3n3d• 1 year ago

Exactly. Btw rust toolchain is quite complicated while a code that was tanspiled to C might be as well compiled to e.g. 6052

tetha• 1 year ago

This is a fairly common technique in compiler construction and programming language research: Don't try to emit some machine code, instead emit C or an IR for clang or GCC. And suddenly your little research language (not that rust is one) is executable on many, many platforms, can rely on optimizations the compilers can do, has potential access to debug handling, ..

widforss• 1 year ago

Regarding the other way, I guess a lot of (practically) legal C wouldn't compile to Rust at all due to the language's restrictions and C's laxness, while I think all Rust could be translated to C.

Someone• 1 year ago

This project doesn’t have that as a goal. In fact, it doesn’t even have “Rust to C compiler” as a goal. https://github.com/FractalFir/rustc_codegen_clr:

“ The project aims to provide a way to easily use Rust libraries in .NET. It comes with a Rust/.NET interop layer, which allows you to easily interact with .NET code from Rust

[…]

While .NET is the main focus of my work, this project can also be used to compile Rust to C, by setting the C_MODE enviroment flag to 1.

This may seem like a strange and unrelated feature, but the project was written in such a way that this is not only possible, but relatively easy.”

It also doesn’t mention for which version of C it produces code. That may or may not hinder attempts to use this to run rust on obscure platforms.

teo_zero• 1 year ago

What is the point of compiling rust to C?

To address platforms that don't support Rust. TFA mentions NonStop, whatever it is.

vbitz• 1 year ago

Fault-Tolerant mainframe type systems.

https://en.m.wikipedia.org/wiki/NonStop_(server_computers)

steveklabnik2• 1 year ago

Not only does NonStop not support Rust, but apparently they failed to port gcc to it, even. So compiling Rust straight to C itself is pretty much the only option there.

nickpsecurity6• 1 year ago

They are amazing machines designed for fault tolerance (99.999% reliability). The Wikipedia article below has design details for how many generations were made. HP bought them.

https://en.m.wikipedia.org/wiki/Tandem_Computers

I think it would be useful in open-source, fault tolerance to copy one of their designs with SiFive's RISC-V cores. They could use a 20 year old approach to dodge patent issues. Despite its age, the design would probably be competitive, maybe better, than FOSS clusters on modern hardware in fault tolerance.

One might also combine the architecture with one of the strong-consistency DR'S, like FoundationDB or CochroachDB, with modifications to take advantage of its custom hardware. At the local site, the result would be easy scaling of a system whose nodes appeared to never fail. The administrator still has to do regular maintenance, though, as the system reports component failures which it works around.

arghwhat• 1 year ago

Using C compiler infrastructure, taking Rust where rustc/llvm does not go. Proprietary platforms with proprietary compilers for example.

oulipo• 1 year ago

I guess it's to target platforms (like some microcontrollers) which don't yet have a native Rust compiler, but often do have a C compiler?

vblanco• 1 year ago

Game consoles generally only offer clang as a possibility for compiler. If you can compile rust to C, then you can finally use rust for videogames that need to run everywhere.

dcow2• 1 year ago

I don’t think I’ve ever heard those two terms “video game” and “run everywhere” in the same sentence. Bravo.

koakuma-chan46• 1 year ago

Is Steam Deck a monopoly yet? I feel like if your game compiles to Linux, you can target pretty much every market out there.

jeroenhd3• 1 year ago

To use rust in places where you can only use C. I imagine there are quite a few obscure microcontrollers that would benefit greatly from this pipeline.

Hell, you might finally be able to get Rust into the Linux kernel. Just don't tell them the code was originally written in Rust to calm their nerves.

pixelfarmer• 1 year ago

If I see something like "At least on Linux, long and long long are both 64 bits in size." my skin starts to crawl. Not only that, but GCC defines __builtin_popcount() with unsigned int / long / long long, respective, i.e. even in the text it should be mentioned correctly (unless a different compiler uses signed types there ... ugh). The call is done with unsigned, using uint64_t as a type-cast, but using a fixed __builtin_popcountl() which translates to unsigned long. There are systems where this will fail, i.e. the only safe bet to use here is __builtin_popcountll() as this will cover at least 64 bit wide arguments.

Also, if a * b overflows within the result type, it is an undefined behavior according to the C standard, so this overflow check is at least not properly portable, either, and the shown code for that is actually buggy because the last A1 has to be A0.

No idea why all that gets me so grumpy today ...

dlahoda• 1 year ago

thank for PR. very fast turn around.

FractalFir6• 1 year ago

Correct me if I am wrong C, unsigned overflow is well-defined - at least the GCC manual says so, but I'll have to check the standard.

https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...

Since signed multiplication is bitwise-equivalent to unsigned multiplication, I use unsigned multiplication to emulate UB-free signed multiplication. The signed variant of this overflow check is a bit harder to read because of that, but it still works just fine.

bool i128_mul_ovf_check(__int128 A0 ,__int128 A1 ){

bb0:

if((A1) != (0)) goto bb1;

return false;

bb1:

return (((__int128)((__uint128_t)(A0) * (__uint128_t)(A1))) / (A1)) == (A1);

}

As for using `__builtin_popcountll` instead - you are right, my mistake. Thanks for pointing that out :).

I did not use the word "unsigned" before long long for the sake of readability - I know that repeating a word so many times can make it harder to parse for some folk. The project itself uses the correct types in the code, I was just kind of loose with the language in the article itself. My bad, I'll fix that and be a bit more accurate.

Once again, thanks for the feedback!

tialaramex• 1 year ago

Yes, the C and C++ unsigned types are analogous to Rust's Wrapping<u8> Wrapping<u16> Wrapping<u32> and so on, except that their size isn't nailed down by the ISO document.

zwnow• 1 year ago

Why would I use a tool that doesn't pass all tests?

01HNNWZ0MV43FF• 1 year ago

To not write C

haswell• 1 year ago

The post is an update on the status of an ongoing project.

This is an update on the progress I have made on my Rust to C compiler.
There still are about 65 tests that need fixing, but they all seem to have pretty similar causes. So, fixing them should not be too difficult.

cbmuser7• 1 year ago

I am still waiting for any of the alternative Rust front- or backends to allow me to bootstrap Rust on alpha, hppa, m68k and sh4 which are still lacking Rust support.

Originally, the rustc_codegen_gcc project made this promise but never fulfilled it.

Aurornis3• 1 year ago

to allow me to bootstrap Rust on alpha, hppa, m68k and sh4

Do you actually use all four of those platforms, or is this an arbitrary threshold for what you consider a complete set of platform support?

im_down_w_otp2• 1 year ago

They're still common (except for alpha) platforms in some market segment specific corners of embedded development. So, maybe for those purposes?

Though, the trend I'm seeing a lot of is greenfield projects just migrating their MCUs to ARM.

cbmuser7• 1 year ago

I am actively maintaining all of these within Debian.

Plus, there is a very vibrant community around the Motorola 68000 and SuperH CPUs thanks to the Amiga, Sega Dreamcast and many other classical computer systems and consoles.

hedgehog• 1 year ago

Did they abandon that goal? Last I heard it was still under development.

cbmuser7• 1 year ago

Well, the promise was that rustc_codegen_gcc would reach its goals very quickly which is why several people dismissed projects such as gccrs.

But it turns out that rustc_codegen_gcc still hasn't delivered and it seems the project has fallen asleep.

shakna• 1 year ago

"m68k-unknown-linux-gnu" was merged as a Tier-3 target for Rust, wasn't it? [0]

[0] https://github.com/rust-lang/compiler-team/issues/458

cbmuser7• 1 year ago

Yes, it was me that did the work on the Rust side. It doesn't work yet though as progress on the LLVM side is very slow.

jedisct12• 1 year ago

rust still doesn't even support OpenBSD on x86_64...

mrweasel• 1 year ago

Do you mean x86 (as in 32bit)? Because I'm fairly sure that there's a Rust package available on x86_64 ( and aarch64, riscv64, sparc64 and powerpc64).

dralley3• 1 year ago

Rust has Tier 3 support for OpenBSD on x86_64

jedisct12• 1 year ago

Nim to C compiler, 100% test pass rate.

alexpadula2• 1 year ago

Rust to C? Why would someone do that. Just write C.. if you can figure rust out you surely can figure C out and be proficient.

alexpadula2• 1 year ago

I will read further into the project just off the bat I don’t get the point. Good luck it looks quite extensive :)

AS04• 1 year ago

Because of the niceties of Rust, combined with the widespread compatibility and architecture support of gcc / C compilers in general?

Rust is a modern language, with package management, streamlined integrated build/testing tools, much less cruft, and lots of high-level features and syntax that people actually like. C is neat but complex codebases benefit from modern languages that help in building robust abstractions while still maintaining the speed of C. Not to mention, of course, the borrow checker and memory safety.

AlotOfReading• 1 year ago

So you can get the benefits of Rust on platforms that rustc doesn't support. Seems pretty straightforward.

wolrah• 1 year ago

It seems like there's a healthy dose of "because it can be done" in play here, but also because there are a lot of platforms that are not supported by Rust where a Rust-to-C converter that generated standard-enough code could be used to bridge the gap.

nullpoint4202• 1 year ago

Would it be possible for Rust to output LLVM IR? Would that make it easier to port if they have a LLVM frontend?

guipsp• 1 year ago

This comment is strange, given that LLVM is rust's most mature backend

woodruffw3• 1 year ago

I think the GP means emit LLVM IR directly. And the answer to that is yes; you can pass a flag to rustc that will emit the IR[1].

[1] https://stackoverflow.com/questions/39004513/how-to-emit-llv...

1vuio0pswjnm72• 1 year ago

"Most components of std are about 95% working in .NET, and 80% working in C."

.NET

Core tests 1662 39 12 97.02%

Core tests 1419 294 82.83%

Missing from HN title: The "95%" pass rate only applies to .NET. For GCC/Clang it is only "80%".

FractalFir6• 1 year ago

Sorry, the README was out of date. Those numbers are from the beginning of the year, and now they are: | .NET Core tests | 1764 | 48 | 20 | 96.29% | | C Core tests | 1712 | 71 | 8 | 95.59% |

1vuio0pswjnm72• 1 year ago

Has anyone tested this project on NetBSD.

https://github.com/dotnet/coreclr/pull/4504/files

Any reason why it would not work.

Rust to C compiler – 95.9% test pass rate, odd platforms

Related Stories