C2rust: Transpile C to Rust

by juancampa • 4 years ago

140 87 4 years ago

detaro5• 4 years ago

Have their been any large projects that used this as a starting point for a port? I would be curious how it works out in practice.

billconan• 4 years ago

But what about borrow checking? Will the transpiled code be runnable.

qw3rty012• 4 years ago

it doesn't convert pointers to references, it just uses pointers, so the borrow checker isn't invoked.

estebank• 4 years ago

The transpiled code will use pointers, it will not transform C-isms that could map to Rust-isms (like borrowing instead of pointers, or iterators instead of pointer arithmetic). This is meant to be only the first step in a Rust refactor.

https://galois.com/blog/2018/08/c2rust/

https://github.com/immunant/c2rust/wiki/Known-Limitations-of...

steveklabnik2• 4 years ago

What I am most curious about is the final paragraph of https://github.com/immunant/c2rust#acknowledgements-and-lice...

There was a while there where they were trying to test this out on the cvs codebase, IIRC. It's a good candidate: upstream doesn't exactly move quickly, but is very much a real-world codebase, still in use.

mlindner• 4 years ago

Interesting, this paper also mentions the same DARPA contract: https://apps.dtic.mil/sti/pdfs/AD1084807.pdf

It shows up in this document of contracts: https://www.esd.whs.mil/Portals/54/Documents/FOID/Reading%20...

  * Contract Number: FA875015C0124
  * Performer Name: GALOIS, INC.
  * Agent Name: AFRL, Information Directorate MR
  * Program Name: Cyber Fault-tolerant Attack Recovery (CFAR)
  * Office: I2O
  * Fiscal Year: 2015
  * Obligated ($): 2,099,878

neopallium• 4 years ago

I just started using c2rust on openjpeg [0] (jpeg 2000 encoder/decoder) today and already have it working as a drop in replacement for the C libopenjp2.so on Linux. Still has a lot of unsafe code, but it does work. Which will be a big help with testing during refactoring to idiomatic safe Rust.

c2rust also has a refactor command that helps with refactoring the generated Rust code.

[0] https://github.com/Neopallium/openjpeg/tree/c2rust

pornel• 4 years ago

I've used my homebrew c2rust converter[1] to translate lodepng and pngquant[2] libraries to Rust. My two key takeaways are:

Good test coverage is essential for this. Count how many bugs you've written when you were writing this code for the first time. Even if your bug-rate is 99% better during the rewrite, that may still be a significant number. Fine-grained tests aren't necessary, but end-to-end tests that touch every feature are crucial to catch regressions.

Once the rough conversion is done, it is necessary to refactor the code to take advantage of Rust's idioms to get safety benefits. Just 1:1 conversion is underwhelming, and it feels like replacing gcc with rustc. I did not realize just how recklessly pointer-heavy C tends to be until I saw it through Rusty lens.

The lodepng conversion was "meh". It's a good C code, but its structure was very different from what you'd do in Rust (e.g. Rust prefers generics over pointer casts, iterators over indexing or pointer arithmetic, has interfaces for steaming processing that C lacks). I don't know how far I can refactor the code to Rusty idioms and still call it lodepng :)

OTOH the pngquant codebase was mine, and I'm happy with the results. When converting I took advantage of Rust idioms, and the Rust version is nicer to maintain and even a bit faster.

[1] https://lib.rs/crates/citrus [2]: https://pngquant.org/rust.html

littlestymaar• 4 years ago

Thanks for citrus, I've started experimenting on it after I've read your pngquant blog post[1] the other day, and it's exactly what I was looking for: c2rust does semantically exact conversion, which isn't what I need: I needed a tool to automate the boring syntax conversion, and when doing the idiomatic rustification by hand I can take care about the different semantics of the two languages.

Off course there's a different trade-off when bugs are involved: c2rust shouldn't add any bugs during the conversion, while citrus will.

[1] https://pngquant.org/rust.html

muizelaar• 4 years ago

I converted https://github.com/FirefoxGraphics/qcms and then refactored it to mostly safe Rust. I ran into a number of issues https://github.com/immunant/c2rust/issues?q=is%3Aissue+autho... but it generally worked ok.

I found refactoring the resulting Rust code somewhat error prone and didn't have great success with the automated tools. I'd recommend having a good test suite and suggest adjusting the C before the conversion to avoid using C features that don't translate well like the C preprocessor.

accountofme2• 4 years ago

Immutant did convert the quake 3 source to rust and hot it to run... They have a blogpost about it kicking around....

bpetersen• 4 years ago

we used c2rust in 2019 for the Delta Chat core library; we added some more details about that to the blog post that time [1]

[1] https://delta.chat/en/2019-05-08-xyiv#the-coming-delta-chat-...

acomjean• 4 years ago

We used to call fortran transpired into ada: adatran.

Adatran was terrible. Hard to impossible to edit if something needed fixing. Used none of the features that made Ada a decent language. The very limited code they did this to did work however. This was a huge project and included C and ada code.

What do we call C code transpiled to Rust. Crust?

pcwalton• 4 years ago

What do we call C code transpiled to Rust. Crust?

Fun fact: in ancient Rust, what we now call extern "C" functions were called "crust" functions, pronounced like the word.

hunterb123• 4 years ago

Rust devs are commonly called Rustaceans, so users of this transpiler could circle back to the term Crustaceans.

deltaonefour• 4 years ago

Think of the transpiled code as a compiled binary. Have your build system be able to recognize both languages. So developers work in C and Rust, but they don't actually work in transpiled rust. I guess this is similar to using the FFI.

drran• 4 years ago

Yep. https://github.com/NishanthSpShetty/crust

CRUST

C/C++ to Rust Transpiler

mjcohen• 4 years ago

Many years ago, I used the f2c fortran to c translator. It worked, but produced godawful code. I removed about 75% of the c to get usable code.

masklinn• 4 years ago

You’re misunderstanding the c2rust project though. Just like Walter above is.

The goal of c2rust is not “regularly compile C to Rust and keep compiling that garbage”. The goal of c2rust is “migrate a C codebase to Rust”. That is the tagline of the Git repository, as well as the title of the RustConf 2018 presentation linked in TFA.

The idea is that you convert the entire thing to working (but unsafe and C-equivalent) Rust, then have your entire build pipeline and tooling ready to chip at it and perform the conversion to safe rust, as an alternative to performing the conversion piecemeal and having a C/Rust boundary which you have to keep moving about, and duplicated definitions for the interop.

raverbashing• 4 years ago

Aaah that makes more sense

Because the translation, while it works, is awful

Now, translating everything and then going function by function seems better

foxfluff2• 4 years ago

It seems to "optimize out" volatile reads if the result is not used.

TickleSteve• 4 years ago

If true, that would be a bug. You dont want to remove register reads from devices for example if the device requires it.

tialaramex3• 4 years ago

It looks to me like they're turned into the appropriate Rust intrinsic.

Do you have an example where the read vanishes?

Notice that it's very easy for C programmers to write code they think is performing a volatile read, but isn't, whereas obviously the intrinsics reduce the scope for this error in the Rust (it is also, though that's not relevant here, easy to write C code that depends on imaginary semantics of volatile access and so the code doesn't actually always work, or it works but not for the reason the programmer expected)

foxfluff2• 4 years ago

If you believe there is no volatile read in this code, I'd like to understand why.

    void func(volatile unsigned *a) { *a; }

WalterBright7• 4 years ago

We kinda gave up on translating C into D, as many C constructs were unduly awkward to represent in D. What's working much better is to incorporate a C compiler directly into the D compiler. No need to translate, and the C semantics can be adhered to exactly. (The D compiler is extended to understand the C semantics coming from the C code, although that isn't part of the D specification.)

WalterBright7• 4 years ago

Some examples of awkwardness:

1. C tag name space

2. enum values are placed into the enclosing scope

3. structs defined within a struct definition don't go into that definition's scope

4. `if (a = b)` is not allowed in D

5. unprototyped C function declarations

6. C bit fields

7. C struct declarations without a definition

8. oddities of _Alignas and _Alignof behavior

9. _Generic

10. all the weird C compiler extensions

11. etc.

All these things wind up making translation about 95% feasible, and the rest is a mess.

jeffparsons• 4 years ago

While your approach to this in D is super-cool, and I love seeing more projects embracing it (e.g. `zig cc` for cross-compiling C code), I think it solves a different problem to what they're tackling here.

FTA:

We are developing several tools that help transform the initial Rust sources into idiomatic Rust.

It sounds like this translator they've built may be meant primarily as the first part of a pipeline of tools to help you eventually translate existing C code into idiomatic Rust, rather than just letting you compile C code using the Rust compiler.

The only use case I can imagine personally having for this tool _on its own_ would be in avoiding the hell of trying to target musl with a project that mixes Rust and C.

WalterBright7• 4 years ago

The trouble with translating existing C code, for example, a .h file, is the .h file vendor changes it. Then you've got to figure out what changed, and fold in the differences to the translated file.

It sounds easy enough in theory, but in practice, it's a nightmare. For example, you have no clue if the enum values changed, or the api's acquired an extra argument. Being C, the linker won't give you a clue, either.

This problem simply vanishes when your XLang compiler can actually compile C files.

Animats• 4 years ago

We are developing several tools that help transform the initial Rust sources into idiomatic Rust.

(2019) C2Rust hasn't changed much in a few years.

The Rust you get out of C2Rust is a representation of the pointer semantics of C in unsafe Rust using a library of functions that emulate C operations. This is only useful if you desperately need to compile C with a Rust compiler.

Intelligent conversion of C to Rust is hard, and less useful as time goes on and more lower-level crates become available for Rust.

elromulous• 4 years ago

Hi Walter!

Was compiling into C a consideration? Seems like this side steps some of the compatibility issues (not to mention getting a lot of optimization "for free"), albeit while inheriting any compilation and ABI limitations.

Thanks! P.s. We met at GoingNative2013 - you were very kind with my many questions back then as well!

WalterBright7• 4 years ago

I've considered compiling into C code, but after seeing what cfront (compiles from C++ to C) had to go through, I figured that would be a ton more work than just generating code directly!

Glad I was able to help you at GN2013!

yazaddaruvala• 4 years ago

I feel strongly that this is underrated.

Basically all compilers should be multi-lingual. Especially, rustc given its abilities with the borrow checker. Ideally (within reason for maintenance reasons), even parsers as “plugins”. Still building the same HIR (or AST if applicable) within rustc, but with different parsers.

I’d love to see lot of experiments with Rust syntax in the vein of how CoffeeScript inspired the future of JavaScript.

But still getting all the benefits of incremental compilation, cargo, etc.

akireu2• 4 years ago

Please clarify what do you mean by incorporating a C compiler. Does this mean you're abandoning the "custom C frontend inside the D compiler" effort in favor of something like clang? To me, the other possibility - having *yet another* C compiler to look out for - is just terrifying.

WalterBright7• 4 years ago

Does this mean you're abandoning the "custom C frontend inside the D compiler" effort in favor of something like clang?

No. It means the custom C frontend inside the D compiler, with the semantic routines in the D compiler tweaked where necessary to support C semantics.

ronlobo• 4 years ago

Promising!

Has anybody incorporated an AI into c2rust to do the heavy lifting and learning from the compiler errors to self fix the transpiled code?

speed_spread2• 4 years ago

I doubt an AI could be trained to do that. Anything that cannot be transpiled mechanically probably requires a human decision which will involve analysis and tradeoffs between objectives that the AI could not know about.

gnulinux• 4 years ago

With enough work, anything a human does can be automated. Unless you believe human brain does something non-computable (like e.g. Godel), which makes you a dualist which comes with its own philosophical baggage (how do different types of ontologies interact?).

rgovostes• 4 years ago

Back in the day there was also Corrode: https://github.com/jameysharp/corrode

Discussed here: https://news.ycombinator.com/item?id=12056230

techdragon• 4 years ago

This looks more useful than some other C to Rust tools, as this will work on code directly instead of the finally linked product, allowing you to use it to port larger library collections or SDKs ahead of time for use in a subsequent Rust project. This can also be used on any old random snippet of valid C, (known limitations aside)

This will be fantastic for helping encourage Rust on microcontrollers. The microcontroller world is very C heavy, so libraries for daughter board and other chips, and other example code, is often only published in C, despite the growing ecosystem of microcontroller chips and boards that have good support for Rust, you end up constantly pushed towards C due to the ecosystem basically only using C. Having a good tool to take that C code and give at least a mechanical, non-idiomatic Rust port is just fantastic and I'm looking forward to giving this a shot with a particular add on board SDK that I wanted to use on a Rust supported microcontroller.

mastax• 4 years ago

Not mentioned on this page is the associated refactoring tool (https://c2rust.com/manual/c2rust-refactor/index.html) which IME is too complicated to learn in 15 minutes, but would likely be a very useful investment when translating a large code base.

the-alt-one6• 4 years ago

Why is this a transpiler and not a compiler?

detaro5• 4 years ago

a transpiler is a compiler.

the-alt-one6• 4 years ago

So why is it a transpiler and not only a compiler?

kitd• 4 years ago

Hmm. Transpile C to "Rust"

edit: I see it is part of a broader toolchain, which makes a bit more sense

JoelJacobson• 4 years ago

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

We rely on Emscripten's Relooper algorithm to translate arbitrary C control flows.

Article on why Relooper isn't good enough and the superior Stackifier algorithm, which they probably should be using instead:

https://medium.com/leaningtech/solving-the-structured-contro...

andrew_mason1• 4 years ago

Shame it's not called `crust`. Very cool though!

jokoon• 4 years ago

I'm curious how it manages to work with the borrow checker.

Lorkki• 4 years ago

The end result is unsafe Rust that uses raw pointers. This kind of tool can be used e.g. as a starting point for rewriting codebase piece by piece, retaining the original functionality as a baseline.

C2rust: Transpile C to Rust

Related Stories