A couple weeks ago, Galois and Immunant launched c2rust. Since I wrote one of the best-known C-to-Rust translation tools (Corrode), and since I worked for Galois before I started working on Corrode, I’ve had a number of people asking what I think of this new project.

In short: I have very mixed feelings about it.

First, the positives:

  • While I haven’t looked very carefully at c2rust, at a quick glance it looks like another good example of the high-quality engineering work I expect from Galois.

  • I plan to deprecate Corrode and encourage people to work with c2rust instead. It’s probably the best choice today for your first steps for translating C projects to Rust.

That said, I’m not pleased about the story behind how c2rust came to exist.

I started working on Corrode in mid-2016. Initially I was just curious if such a thing could work at all, but by the end of that year I had a three month contract from Mozilla that enabled me to develop it further. With Mozilla’s support, I proved that the only real limits were around translating certain “features” of C that Rust didn’t provide. (Some of those are now supported, so there’s very little C that doesn’t have a direct translation to Rust today.) More importantly, I demonstrated that Corrode was a useful part of the story for how to translate a large C project to Rust.

In January 2017, I heard from some of my friends at Galois that following Mozilla’s funding, my results had caught Galois’ attention, and they had an idea for how to apply Corrode in a research project they were doing. It was, and is, a cool project! A web search for contract number “FA8750-15-C-0124” will find you some of the published results, including c2rust itself, since they all legally have to acknowledge who funded them. From public sources referencing that contract number, such as Michael Franz’ CV, you can also discover that:

Galois proposed to sub-contract with me over the 17 months of this extended contract, which would have been a huge deal for me as a self-employed independent contractor. They wanted me to improve C-to-Rust translation for use in RADSS, which I still think is a promising idea.

It took six months before Galois could finally give me a contract for my lawyer to review. I believe much of that delay was at DARPA due to the change in presidential administration, and anyway I know it’s not uncommon for these things to get dragged out in the best of situations. Unfortunately, during that interval I was declining other work based on the expectation that this contract would be taking a significant fraction of my time—a mistake, in hindsight.

Meanwhile, I continued to work on Corrode, but discovered that I was hitting a wall due to early design choices I had made. So I started putting my time into figuring out what a “Corrode version 2” would look like if I started from scratch. As Galois started gearing up to work on the new contract, I had a video call with maybe 6-8 people there where I explained that I thought the existing Corrode code base was a dead end and we should build this new tool I envisioned.

When I finally got to see my contract, including all the pass-through terms required by DARPA, it turned out that there was no way I could sign it.

For most contracts, including this one, DARPA requires a wide range of standardized contract terms, including “publication review”. If you want to say anything in public about your work under the contract, somebody at DARPA needs to review what you’re going to say first. (This is DFAR 252.204-7000 if you want to read the exact terms I would have been subject to.) I assume this is based on some fear that a contractor will accidentally leak classified information, or something; I’m not sure how often DARPA rejects an information disclosure, or why.

The important thing is that publication review even applies to every git push to a public repository. I’m told that publication review can take up to a month, and anyway of course there’s no guarantee they’ll allow it. So any software project subject to these terms can’t possibly be governed as an open source project. The contractor can make the source code public when they’re done with the project, as Galois et al have recently done with c2rust, but practically speaking it’s impossible to involve a wider community during the development process.

Once I understood the contract terms, I tried to find a way around them. I already had a small but active open source community around Corrode, and to me, it was critical to be able to keep them involved. (It’s worth noting that the most prolific contributor to Corrode got hired at Galois during this period and went on to make significant contributions to c2rust, so at least one person got to stay involved.)

Legally speaking, since I’d argued that the project should be a from-scratch rewrite, c2rust is not a derived work of Corrode in the copyright sense, and of course I hadn’t filed any patents that could be infringed. So from the perspective of Galois’ lawyer, there was nothing to negotiate: the project would happen under DARPA’s terms, which Galois had already agreed to, or it would not happen at all.

From my point of view, on the other hand, I was being asked to work on software that would replace my existing GPL work, without leaving me any way to support my existing community. Because of the publication review terms, I would not even be able to speak at conferences or write blog posts about any new work I did. And although I trusted that Galois intended to publish the source code on completion, I couldn’t count on DARPA permitting it, and Galois couldn’t make any promises in my contract. I knew if I spent a year working on this project and then found out that it was going to be kept in-house forever, I would feel that my project and my effort had been stolen from me, no matter how much I got paid in the meantime.

So I refused. The project lead accepted my reasons and suggested that perhaps I could give them private tech talks about what I’d learned while working on Corrode, which they’d pay me some small amount for out of their overhead budget so it wouldn’t be tied to DARPA’s contract terms. As a consolation prize it wasn’t much of an offer, and I got exhausted just thinking about the effort involved in putting together useful presentations on that topic, so I didn’t do that either.

I didn’t hear anything further about the project until a couple weeks ago when c2rust.com went public.

Architecturally, c2rust looks exactly like what I planned for a from-scratch rewrite of Corrode, and the engineers clearly learned a lot from my work. This is not surprising, since I told them this is what they should build, and their initial development plan and early commit history talk about Corrode.

What is surprising is that none of the documentation acknowledges any prior work. Not my own work, and not ideas like Emscripten’s “Relooper” algorithm either. The Relooper algorithm was critical for Corrode’s support for arbitrary C control flow, and c2rust followed my example there too. I’m optimistically hoping that the missing acknowledgements are just held up by DARPA publication review, and will quietly appear in the next few weeks.

So I’ll say it again: While I personally have very mixed feelings about how c2rust came about, it is the tool I asked for, and probably the best tool to use instead of Corrode going forward.

Of course, there’s plenty of work to do yet, just like there was with Corrode. There are still known limitations of c2rust. And just like with Corrode, the output of c2rust is not usually idiomatic or safe. Glancing at some examples of c2rust output, I can see so many improvements that I could automate, given the time, but I can’t afford to work on these projects in my spare time at this point.

I am, however, still available as a contract developer. If you need someone who can apply computer science theory to practical engineering problems, and who can produce a prototype that DARPA thinks is worth a big pile of money, hit me up at jamey@appliedrefinement.com.