Eurydice: a Rust to C compiler

https://jonathan.protzenko.fr/2025/10/28/eurydice.html

by todsacerdoti • 8 months ago

189 123 8 months ago

jonathan.protzenko.fr

Cool. One should perhaps mention some prior art:

    rustc_codegen_clr is an experimental Rust compiler backend(plugin), which allows you to transpile Rust into .NET assemblies, or C source files.[0]

[0]: https://github.com/FractalFir/rustc_codegen_clr

oconnor663• 8 months ago

We recommend using Nix to easily ensure you are running the right versions of the tools and libraries.

Ooof I remember when everything used to be like this. Cargo has really spoiled me.

ValtteriL2• 8 months ago

Can Cargo install deployment tools like Ansible? I find myself using nix for those kind of tools despite how good $lang package manager is.

ris• 8 months ago

Using nix to install Ansible, oof you're hurting me..

antonvs3• 8 months ago

Cargo isn't intended for that. If there was something like Ansible implemented in Rust, then you could use Cargo to install it.

kamov• 8 months ago

You can use both Nix and Cargo at the same time, and they accomplish different things. Nix's purpose is more like rustup, except it works for each program on your computer

skavi• 8 months ago

Cargo does not attempt to solve the same problems as Nix (if you depend on any software not written in Rust). A checked in Nix shell is genuinely great documentation on the expected system environment.

apitman3• 8 months ago

I use Rust and C at work. I quite enjoy Rust, but I currently have no reason to believe C won't outlive it, by a lot.

po1nt• 8 months ago

Well, Fortran is still used somewhere too

rahen• 8 months ago

You mean everywhere. It's just hidden behind abstraction layers or Fortran libraries like BLAS/LAPACK, which are used by NumPy, R, Julia, MATLAB, Excel, TensorFlow, PyTorch (for some backends), and basically anything that involves linear algebra.

hu3• 8 months ago

And I think Zig will gradually eat a large piece of the C pie that would otherwise be eaten by Rust.

pjmlp5• 8 months ago

I doubt it, unless it sorts out its use after free issues, embraces binary distribution used in commercial world, and gets adoption by an OS vendor.

opem2• 8 months ago

Jai is also on the que

apitman3• 8 months ago

Currently Zig has the same issues as Rust in this context, primarily depending on a compiler that's too complex for a single person to maintain if necessary.

But in Zig's case it seems there's a pretty good chance that will change if they're able to drop LLVM in the future.

pjmlp5• 8 months ago

Until specific industry standards like POSIX, all Khronos APIs, UNIX like systems get rewriten into something else, it is going to stay around.

Hence why it should be a priority for WG14 to actually improve C's safety as well, unfortunately most members don't care, otherwise we would at least already have either fat pointers, or libraries like SDS on the standard by now.

thristian• 8 months ago

In 1983, AT&T released the fifth version of Unix, called "System V". Part of the release was an ABI specification for how the different parts of the system would talk to one another. Notably, the main portion of the spec described portable things like the file-format of executables, and the details for each supported platform were described in appendixes.

The SysV ABI is still used to this day, although the specification itself has withered until only two chapters remain[1], and CPU vendors still publish "System V ABI appendix" documents for platforms that System V's authors could not have dreamed of[2].

C as an interface is going to be around for a very long time, like POSIX and OpenGL and the SysV ABI standard. C as an actual language might not - it might wind up as a set of variable types that other languages can map into and out of, like what happened to the rest of the SysV ABI specification.

[1] https://www.sco.com/developers/gabi/latest/contents.html

[2] https://wiki.osdev.org/System_V_ABI#Documents

IshKebab2• 8 months ago

The C ABI will definitely stick around. That doesn't necessarily mean C will. (Though it probably will have a very drawn-out death.)

apitman3• 8 months ago

Hence why it should be a priority for WG14 to actually improve C's safety as well

Sorry should have been more clear. I'm talking specifically about C89, or maybe C99.

mustache_kimono6• 8 months ago

I currently have no reason to believe C won't outlive it, by a lot.

My reaction is kind of: "So what?" I really don't care about the relative lives of languages and don't really understand why anyone would. Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?

IMHO it would be completely amazing if magically something 10x better than Rust came along tomorrow, and I'd bet most Rust people would agree. Death should be welcomed after a well lived life.

To me, the more interesting question is -- what if efforts like c2rust, Eurydice, TRACTOR and/or LLMs make translations more automatic and idiomatic? Maybe C will exist, but no one will be "writing" C in 20 years? Perhaps C persists like the COBOL zombie? Perhaps this zombification is a fate worse than death? Perhaps C becomes like Latin. Something students loath and are completely bored with, but are forced to learn simply as the ancient interface language for the next millennia.

Is that winning? I'd much rather people were excited about tech/a language/a business/vibrant community, than, whatever it is, simply persisted, and sometimes I wish certain C people could see that.

tormeh3• 8 months ago

Honestly I'd be a bit disappointed if something better came along tomorrow. Just as we as an industry spent all this effort moving to Rust something better comes along? Lame. Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace so we as an industry don't totally "waste" tons of time on transitioning between short-lived languages. Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages than what they're using, so this is not a realistic issue.

pjmlp5• 8 months ago

COBOL has enough business money around to get new tools and ISO standards[0], so it is unlikley to think otherwise regarding C.

https://www.rocketsoftware.com/en-us/products/cobol/visual-c...

[0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html

uecker4• 8 months ago

I plan to be writing C for the next decades even for new projects, because I think it is a great language, and I appreciate its simplicity, fast compilation times, stability, and portability.

I am happy if people are excited about Rust, but I do not like it too much myself. Although I acknowledge that it contains good ideas, it also has many aspects I find problematic and which why I do not think we should all switch to it as a replacement for C.

flohofwoe8• 8 months ago

I bet that C won't just be around for legacy projects, but also for writing new code for at least the next 30 years.

GhosT0783• 8 months ago

In my timeline, something 10x better than Rust came along in 1995.

mamcx• 8 months ago

yeah, this is the actual good mindset.

C has never been a particularly good language, and is so good that finally (with tons of pushbacks!) there is an alternative that make the case so strong that is at least considered the possibility that will come the very happy day where C will be our past.

The only, true, real blocker is that C is the ABI. But if we consider the possibility that C can AND should be the past, then the C Abi can finally adds sophisticated things like Strings and such, and maybe dreaming, algebraic types (ie: the C will be improved with the required features so it can evolve the ABI, but not because will be a good language for write it (manually) on it).

And to reiterate: C should finally be a real assembly language, something we not need to worry about.

iberator2• 8 months ago

COBOL is actively developed and maintained. It's far from being dead. Its working flawlessly and will be for the next few decades :)

I bet you never wrote single program in Cobol...

testdelacc1• 8 months ago

Neither needs to outlive the other to be individually useful.

The way I see it, the longer something is actively used, the greater the chance it’s going to stick around. I’m bullish on rust but I’m equally bullish that C will last a long, long time.

But it’s not an either-or here. Both are good at certain things and can coexist. Like they’re coexisting in the Linux kernel for example.

gritzko• 8 months ago

Correct me if I am wrong, but C is the “greatest common denominator” for several decades already. Java, .NET, go, Rust are very much ecosystems-in-themselves. From the practical standpoint, they can not use each other’s code, but they all can use C libs.

flohofwoe8• 8 months ago

Technically it's only the C API that's important, the implementation behind the C API can be written in any language. The downside is though that you still need a language toolchains X, Y, Z to compile the implementations. Transpiling everything to C removes that one dimension from the build process.

ahartmetz3• 8 months ago

Unless something similar to but better than Rust comes along soon, I expect both Rust and C to live "forever".

sakompella2• 8 months ago

Unfortunately, I really doubt long rust's "forever" will last in the wake of the `time` crate controversy. I can't see like a lot of good options in that place from the perspectives of the rust-std maintainers, but it might've just been worth it to wait for a new edition or similar.

Wowfunhappy2• 8 months ago

It also feels to me like Rust is trying to replace C++ more-so than C.

drnick13• 8 months ago

There SO MUCH C++ out there that it won't ever be replaced. For one, Rust (or plain C) isn't a good choice for big applications (GUI, video games, web browsers, and many others) where classic OOP is so useful.

BobbyTables2• 8 months ago

Not saying it isn’t neat, but WHY?

Seems like the kind of thing that happens before a language is natively supported by a compiler.

viraptor• 8 months ago

If only the article started with an explanation...

thrance• 8 months ago

There's literally a section named "Why?" in the article.

procaryote• 8 months ago

They want to use rust but can't, because they need C compatibility, e.g. because they're providing a library or wants to support platforms that rust don't.

It's at least a less bad idea than I expected originally – I've mainly seen people try to use transpilers to sneakily start using the language they prefer as part of a larger code base, with all the obvious problems.

It's still not great as you now have an additional translation step to deal with. You will at some point need to look for bugs in the generated C layer, which will really suck. Users of the C library can't read your source to understand what it does internally without an extra step to figure out what rust code the thing they use corresponds to, etc.

If you want to provide a C library, write C. If rust isn't an option because it doesn't work for your customers who use C, don't use rust.

zozbot2342• 8 months ago

You can write a C-compatible binary library in Rust (see the cdylib target) and cbindgen can then generate proper C header files for any C-ABI interfaces exposed in Rust code. A full Rust-to-C compiler should only be needed for targets that have some C compiler available but are just not supported by the current Rust toolchain.

drwu• 8 months ago

Rust compiler can be easily bootstrapped.

nutjob2• 8 months ago

Another Rust compiler with a C backend:

https://github.com/thepowersgang/mrustc

ValtteriL2• 8 months ago

Github: https://github.com/AeneasVerif/eurydice

opem2• 8 months ago

Cool, loved this! These tools would be needed in the near future to manage the tech debt safe rust is compounding.

bloppe2• 8 months ago

Rust compiles to LLVM IR. I'm pretty surprised that building this transpiler was considered a better use of time than writing an LLVM backend for whatever "weird embedded target" might need this.

aw16211073• 8 months ago

In fact there used to be a C backend for LLVM, but it was removed in LLVM 3.1 [0]. JuliaHub has resurrected it as a third-party backend [1], though I have no idea if there is any interest in upstreaming the work from either end.

[0] https://releases.llvm.org/3.1/docs/ReleaseNotes.html

[1] https://releases.llvm.org/3.1/docs/ReleaseNotes.html

fithisux2• 8 months ago

The refs are duplicated.

rcxdude• 8 months ago

This would cover many different weird embedded targets, and a lot of those targets can be an utter pain to target with a compiler.

Wuzado• 8 months ago

Sometimes you may need to deal with odd proprietary processors with limited and flawed knowledge about them.

For example, in the 37c3 talk "Breaking "DRM" in Polish trains" by the folks from Dragon Sector (I highly recommend watching it), they needed to reverse-engineer Tricore binaries, however they found the Ghidra implementation had bugs.

As for the PLCs, the IEC 61131-3 functional block diagrams transpile to C code which then compiles to Tricore binaries using an obscure GCC fork. Not saying that anyone would want to write Rust code for PLCs, but this is not uncommon in the world of embedded.

mistrial9• 8 months ago

.. there is some humor in the string

"Breaking "DRM" in Polish trains"

SkiFire13• 8 months ago

Rustc supports backends other than LLVM btw

forgotpwd162• 8 months ago

And someone has made (https://github.com/FractalFir/rustc_codegen_clr) a backend targeting C (alongside .NET/CIL).

bangaladore2• 7 months ago

Do any of the supported backends work in practice though?

My understanding is pretty much all of them are extremely immature and not a drop in replacement.

flohofwoe8• 8 months ago

If you write a library in Rust and want to make that library available to other language ecosystems, not requiring a Rust compiler toolchain for using the library is a pretty big plus - instead create a C source distribution of the library, basically using C as the cross-platform intermediate format.

torginus• 8 months ago

There are many kinds of IRs in compilers - I'm not familiar with how Rust works, but for example GCC has an intermediate representation called GENERIC, which is a C-like language that preserves the scoping and loops and branches of the inputted C code.

Lower level representations also exist - since C has goto, you can pretty much turn any SSA IR to C, but the end result won't be readable.

NooneAtAll3• 8 months ago

I have never seen any guides or blogs about writing LLVM backend

and considering how long compiling LLVM takes... it's reasonable to go for other options

Bratmon• 8 months ago

I think you may not be familiar with how embedded development works.

Most teams who write code for embedded devices (especially the weird devices at issue here) don't have the hardware knowledge, time, or contractual ability to write their own compiler backend. They're almost always stuck with the compiler the manufacturer decided to give them.

aw16211073• 8 months ago

I think the approach would not be to alter the manufacturer's compiler directly, but to run your Rust code through a separate Rust-to-C compiler then feed that output into the compiler the manufacturer gave you.

bloppe2• 8 months ago

You're right. But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.

But ya, I believe this project exists for a meaningful purpose, I'm just surprised.

zem• 8 months ago

this effectively writes a backend for all the weird targets at once, since pretty much everything out there has c compiler support

bangaladore2• 7 months ago

Transpiling to C means you get all architectures gcc supports.

Building a backend for LLVM to a single architecture, well, only provides access to that architecture.

pankajdoharey• 8 months ago

In a world where Crabs are trying to rewrite everything in their favourite Crab Speak its nice to see the Reverse. I wonder if it coulkd be used to translate Rust compiler itself to C :-D

Y_Y2• 8 months ago

https://github.com/Rust-GCC/gccrs/tree/master/gcc/rust

There's a Rust compiler in C++ in case that's any good to you

Aissen• 8 months ago

for instance, Rust panics on integer overflow

By default, this is only in debug mode. I recently forgot to add it to release mode on a project, and was surprised when I broke the CI (tests run in debug, I only tested in release mode).

IshKebab2• 8 months ago

The perfect headline to bring the anti-Rust luddites out of the woodwork...

exDM69• 8 months ago

The project itself is cool and useful but the motivating example of crypto (primitives?) isn't great.

Cryptography is already difficult to write in high level languages without introducing side channels via timing, branch predictor, caches etc.

Cryptography while going through two high level compilers, especially when the code was not designed and written to do so is an exercise fraught with peril.

Tbf, this is just nitpicking about the article, not the project itself

the8472• 8 months ago

It's not possible to correctly implement any cryptographic algorithms in any high-level language with an optimizing backend where timing is not considered an observable/perserved property. Currently this includes anything backed by LLVM or GCC, though there's a proposal to introduce such guarantees through a new builtin in LLVM https://github.com/llvm/llvm-project/pull/166702 though those could still be broken by post-build optimizers, like wasm.

d-lisp• 8 months ago

When you think about it, Perseus did use Medusa's head to transform things into stone.

In fact he turned king Polydectes and all of his followers into stone when he went back to Sephiros.

Perseus defeated Medusa by not looking at her in the eyes.

Rust in a sense, allow you to solve problems without having to look directly at memory unsafe behavior.

I would have called this project "Medusa".

protz• 8 months ago

author here; thanks for the suggestion, that'll be a cool name for my next project :-)

jll29• 8 months ago

The original author of the post also

- has designed the Mezzo programming language in his Ph.D. thesis and

- has worked on generating user-friendly C automatically. Most tools that generate C output pretty unreadable/unmaintainable code that you won't like to maintain, so this is a much under-researched topic.

Surac• 8 months ago

I was always told rust uses llvm tokens not produceable by c code to do its magic. Was I informed wrong?

mmastrac• 8 months ago

There are multiple stages of IR in the compiler, basically

SAI_Peregrinus2• 8 months ago

You probably misunderstood. C can represent any program's semantics, since it's Turing-complete (modulo finite memory). C can't encode the lifetimes Rust uses, but those get erased during compilation to MIR. This takes MIR from rustc (where borrow checking has been completed and lifetime annotations erased) and outputs C with the same semantics. LLVM doesn't use tokens not produceable by C, but rustc does.

Grikbdl• 8 months ago

I think it's a reference to certain optimizations possible due to aliasing rules in Rust that are not possible (or maybe only "not straight forward", I'm not sure) in C. So a transpiled program while keeping its semantics might not still compile to equally optimized assembly.

1718627440• 8 months ago

C still has lifetime rules. It just has no syntax for them. What people are bitten with is that they violate the lifetime rules, but their compiler doesn't tell them.

Eurydice: a Rust to C compiler

Related Stories