Hacker News Reader

Comment by xvilka | Hacker News Reader

Much or this can be automated with c2rust[1][2]. They recently published an overview[3] of lessons learned and future directions for Rust and C integration.

[1] https://c2rust.com

[2] https://github.com/immunant/c2rust

[3] https://immunant.com/blog/2019/11/rust2020/

View on HN

That doesn't really translate C to Rust, it compiles it to unsafe Rust with all the weaknesses of the C code. It doesn't even use Rust arrays. You would not want to maintain what comes out. It turns

    p[j] = p[j-1];

into

    *p.offset(j as isize) = *p.offset((j - 1 as libc::c_int) as isize);

which is unmaintainable.

If you put in

    void insertion_sort(int const n, int const p[])

you get

    pub unsafe extern "C" fn 
        insertion_sort(n: libc::c_int,
                       mut p: *const libc::c_int)

C has no way to say how big p is. (Biggest flaw in the design of C). That info is essential to translating this properly. The translator needs either a hint from the user, or inference from examining the calls to the function.

Now, if you could stick something like

    ASSERT(LENGTHOF(p) == n);

which would be ignored by C if ASSERT was defined to ignore it, and the Rust translator understood that, it could use a Rust array, which has a size. Now the output Rust code could use subscripts properly.

Generating constraints like that is a hard problem, but providing an interactive tool which prompts the user on where to insert them is not.

C2Rust contributor here. You are right that the transpiler preserves all the weaknesses of C in its output. (Thanks for taking a look :)

C2Rust includes a refactoring tool that (in some, currently very limited circumstances) let us lift raw C pointers to Rust references (to slices) as a step towards using safe Rust constructs. This is obviously not something that can be 100% automated but our goal is to see how far we can reasonably go. Lots of work ahead but we 100% agree that some level of automation is highly desirable here.

"it compiles it to unsafe Rust with all the weaknesses of the C code"

Isn't that the idea?

Sure, it makes it into essentially a blob of uneditable code. But it allows you to integrate it with rust code and build the whole thing together.

Not when it's being pitched by gp as an alternative to rewriting such that the rewrite is the primary code. This particular scenario is one where an opaque blob is not at all the goal, and thus c2rust is not a valid strategy

It seems that part of the goal of c2rust was to retain the C memory layout in memory. If that's not required, C arrays can be translated to Rust arrays. Except for some corner cases involving casts and pointer arithmetic, that should work, and generate much cleaner output code. You can detect those, at least. For pointer arithmetic, do the pointer arithmetic and convert it to a subscript before indexing. Then you have bounds checks.

This is a classic problem with computer language conversion - you lose the idioms of both the input language and the output language in translation.

> it makes it into essentially a blob of uneditable code.

No, it doesn't. It retains comments, the names of variables, and most of the structure of the code. You're meant to be able to factor the unsafe behaviours out incrementally from there (and there are a lot of bundled and associated tools meant for exactly that). I ran an example through c2rust the other day and rustc told me immediately that I had functions that didn't need to be marked unsafe. switch statements are probably the thing that suffers most with c2rust, though I think there's a tool for that.

My favorite translation so far is Duff's Device. In old C from Wikipedia modernized it's roughly:

    void send(volatile short *to, short *from, int count)
    {
        int n = (count + 7) / 8;
        switch (count % 8) {
        case 0: do { *to = *from++;
        case 7:      *to = *from++;
        case 6:      *to = *from++;
        case 5:      *to = *from++;
        case 4:      *to = *from++;
        case 3:      *to = *from++;
        case 2:      *to = *from++;
        case 1:      *to = *from++;
                } while (--n > 0);
        }
    }

While the result from c2rust is even less maintainable than original interleaved-loop-switch, I'm impressed that it looks like they have a robust way to handle bizarre control flow. (The output from c2rust is not reproduced here to save space, you can try it on https://c2rust.com/ )

Do you actually have those C commands in your preprocesser? Sorry if the question is pretty basic but I’m learning C. It’s the one language you can’t avoid! (e.g. Erlang VM is written in C) Any info appreciated :)

Those aren’t builtin macros, no. There is “assert.h”, which has an ‘assert’ function/macros/thing. The LENGTHOF macro I’m not as sure. There are ARRAY_LEN macros that I’ve seen — being sizeof(x)/sizeof(x[0]) — but that’s all compile time, and wouldn’t lend itself here too well.

For C, almost everything is written by you, especially when it comes to macros. There are some “basics” that you pick up here and there, which you can copy-paste more or less.

The C preprocessor is a beautiful thing, but can get a bit tedious. Sometimes a lot tedious. But shit is textual replacement powerful!

I thought Erlang VM was written in Erlang, maybe the first few versions where written in C.

The compiler and most of the standard library are written in Erlang, the VM and key components of the standard library are written in C.

The first versions were written in Prolog.

A lot of established C codebases are really preprocessor heavy. E.g. https://github.com/remacs/remacs

Compile C to Wasm and run in a Rust hosted Wasm sandbox.

Including the Heartbleed version of OpenSSL if one so desires.

Do you know if there's a "rust2c" tool?

mrustc can compile Rust to C.

The verification ecosystem for C is the last reason that tool-augmented C is safer than Rust. A Rust-to-C compiler might let Rust leverage that. So, thanks for the tip.

I don't think mrustc speaks the C dialects that are friendly to tool augmented verification currently, FWIW. The focus of that project is from source boot strapping, and support for archs that don't have LLVM backends.

Reply on news.ycombinator.com