Hacker News Reader

Comment by Animats | Hacker News Reader

This is compiling C into very unsafe Rust as a target language:

    pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int)
 -> () {
        let mut i: libc::c_int = 1i32;
        while i < n {
            let tmp: libc::c_int = *p.offset(i as isize);
            let mut j: libc::c_int = i;
            while j > 0i32 && *p.offset((j - 1i32) as isize) > tmp {
                *p.offset(j as isize) = *p.offset((j - 1i32) as isize);
                j -= 1
            }
            *p.offset(j as isize) = tmp;
            i += 1
        };
    }

The output is unmaintainable, like the output from a compiler. This isn't translation into usable Rust.

A C++ to Rust translator would be a good thing, but it has to be much smarter than this. This doesn't even comprehend arrays in C.

A good translator might need some human help to deal with C's ambiguities. Like "Is this an array? (Y or N)" How big is it? (Enter expression). Then you get a program that's real Rust. If the user is wrong about the size, safe Rust will either allocate too much space or get a subscript error.

View on HN

I know and agree that unsafe Rust is problematic, but that criticism of this is missing the forest for the trees. The original code is just as unsafe.

Refactoring from unsafe Rust into safe Rust manually is likely to be easier than directly from C into Rust: one is only trying to deal with one small delta (like changing length/pointer arguments into a slice) rather than also having to deal with syntax changes and tooling issues.

As others have said, it is essentially impossible to automatically translate to safe Rust without non-trivial annotation effort, since C the language and C in practice is very different to how Rust guarantees safety. It seems to me that that "annotation" effort is probably better spent going unsafe to safe Rust (where, subjectively, the language is nicer to use, like better enums and less error prone control flow) rather than annotating the original C.

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with the translator being too stupid or the language; neither is something I look for in a tool I use.

No, all memory accesses in C are unsafe in the keyword-in-Rust sense: `unsafe` indicates that an API can be misused to cause undefined behaviour, contrasting to non-`unsafe` code where any potential undefined behaviours will be caught at compile time or runtime, no matter how incorrect the program/use of the API is. Just like C, it is an incorrect Rust program if undefined behaviour actually happens, meaning all uses of `unsafe` have to actually be safe, but it's up to the programmer to ensure this, with less compiler assistance than in normal Rust.

Every single pointer access `*p` or `p[i]` in C has potential for undefined behaviour (e.g. p is NULL, points to an invalid object, or i is out of bounds), and thus the Rust equivalent is surfacing this risk in a more obvious way.

(It would have been clearer if my original comment said: "The C and the Rust both risk undefined behaviour in the same ways", instead of using an overloaded meaning of unsafe in saying that the C is unsafe.)

In the context of Rust, unsafe does not mean incorrect or vulnerable to memory unsafety. Unsafe refers to code whose memory safety has not been proven (by the compiler's static analysis based on ownership and lifetimes, given the assumption of correctness of other unsafe code (so you can look at the proof of memory safety of a program as a whole as an inductive tree of proofs, with the leaves being unsafe code like in `std::Vec`, which is subject to formal and practical scrutiny outside of rustc's static analysis).

By this definition, all C code has unsafe memory accesses. However, it is possible to define static analyses that can prove memory safety of some portions of C programs, and incorporating such a thing into C2Rust would allow it to generate more safe Rust and less unsafe Rust.

> The original code is just as unsafe.

But the translated code being unreadable to humans adds a whole new layer of "unsafe".

I wouldn't call that unreadable at all

While the translated code is harder to read, it's much easier to refactor into compiler-checked safe code than the original C. I think doing the translation as part of a larger migration from C to safe Rust is essentially the only defensible reason to do it, as it doesn't seem like other reasons can justify the risk of (as one of the sibling comments points out) bugs in the translator and the code being unreadable, aka, in an "unnatural" representation of trying to express C idioms in Rust.

That is to say, I don't think humans should be reading or maintaining this code for more than it takes to refactor to be safe(r). (Whether this is how this sort of tool is used in practice is a different question, and one that definitely needs to be considered.)

>The original code is just as unsafe.

That assumes zero translation errors as well as the original C code not relying on a particular compiler's specific implementation of unspecified behavior.

Your first point is of course true, but most statements about the behaviour of code needs to have "assuming no bugs" appended to it, so I'm not sure that it's a particularly interesting point. A more precise interpretation might be that the translator is likely to have more bugs than other components in the pipeline (the compilers and linkers etc.), since it is unlikely to be used nearly as much as them; I wonder if one could do things like compile with rustc and clang and somehow compare the LLVM IR for equivalence (but... I suspect that the code generation patterns for each aren't similar enough).

As for unspecified behaviour... that's true! Again I wonder if clang is a useful component here: I suspect if C code behaves correctly with clang, then the translation to Rust compiled with rustc probably works too, both because the translator uses clang, and because both compilers use LLVM.

The point (in contrast to the usual complaint of Animats) I was trying to convey, but was nitpicked was: a correct translation from fully-specified C to unsafe Rust doesn't add any unsafety. Whether this applies in practice is slightly different, but there's questions about whether pretty much any statement about C code applies in practice: since undefined behaviour is so rife and easy to trigger, many/most programs are outside the specification (fuzzing C programs often results in segfaults---undefined behaviour---and so the program is outside the bounds of C).

Wrapping up, I'll emphasise that the value in this sort of translation is as a stepping stone towards safe Rust, not as a final `unsafe` product.

> I wonder if one could do things like compile with rustc and clang and somehow compare the LLVM IR for equivalence

The approach we've taken so far with C2Rust is to build compiler plugins that instrument C and Rust code so we can dynamically check their behavior when fed the same input.

https://github.com/immunant/c2rust/tree/master/cross-checks

Even though it's translating to unsafe Rust, it does still have some value. In particular, C libraries can be converted into Rust libraries that can be managed via Cargo, avoiding the need to deal with C tooling.

Is that benefit worth the potential for inaccurate translation? Or is it possible to be 100% certain that the Rust functions identically to the C?

Well if you translate it to safe rust at least the worst that could happen is a design flaw.

And you can write oracle tests to catch those.

> the worst that could happen is a design flaw

That's still pretty bad, especially for low-level legacy libraries that aren't supposed to break userspace under any circumstances.

Hence the need for oracle tests.

As a user of a C library in Cargo, you don't need to deal with C tooling, just have it installed.

That means anyone that wants to use a Rust crate that depends on a C library has to somehow install the C library. It's possible that's easy through a package manager, or maybe it's not, and you have to build the C library, and now you have to deal with C tooling.

Some packages give you the option to check for a preinstalled package, and build it if it’s not there.

It works pretty cleanly, but it is true that one toolchain is easier than two.

That only applies to shared libraries. If the crate builds the library and links it statically, you don't see the tooling.

Don't you still need C tooling setup for the crate to build the C library?

Especially on Windows, this can be a pain.

On Windows, if you’re using the MSVC version, which we recommend, then you’ll have that tooling installed anyway; it’s the only way to get link.exe.

> This is compiling C into very unsafe Rust as a target language

It’s basically as safe as the original.

> This isn't translation into usable Rust

It’s slightly more usable, and easier, than FFI to raw C (see other comments about Cargo integration).

I’ve been thinking about language rewrites like this, and generally I’m really torn. If it’s the intention to get rid of your C, it might in fact be easier to use bindgen for the C header translation, and create decent Rustful interfaces that abstract the C. After that maybe use this tool as a starting point to get Rust or possibly just rewrite the section by hand. In either case you’ll be rewriting the logic into safe Rust at some point, otherwise I don’t see a huge point in doing this (other than the Cargo integration, though there are other options for that).

The problem is the type noise, which may or may not be avoidable. Most of the mess you see there is probably better expressed as std::mem::* function calls which give proper names to the operations (you can see one of them, .offset, used here but it's a very general function). I don't think it's a good idea to try to convert C code like this to more complex std::mem calls automatically but once you have the ugly Rust code, it becomes relatively easy to start porting it to be more Rustic.

The bigger issue I see here is that this should be implemented as an iterator. I don't think there's any hope of automatically converting to those though - there's just no C equivalent except pointer arithmetic.

The premise here must be that the translator (human) has the original C code. So answering questions like "is this an array" is as simple as reading the C code to determine that.

Allocating too much space or getting a subscript error seems preferable to unsafety, and something one can hammer out with oracle testing.

Actually, it would be cool if there were generated quickcheck-like oracle testcases alongside this so you could start your translation to safe rust and test along the way.

So answering questions like "is this an array" is as simple as reading the C code to determine that.

If only. Here's the original function definition:

    void insertion_sort(int const n, int * const p)

"p" is really an array. But C doesn't know that. Rust needs to know.

Around 2010, I proposed an extension to C [1] in which you'd write that as

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

Instead of a pointer, you'd use a reference to an array. Same calling sequence - the compiler passes a pointer. But with enough info that the callee knows the array size. Rust needs that info to do its job. Somehow, you have to get that info into a C to Rust translator.

[1] http://www.animats.com/papers/languages/safearraysforc43.pdf

It is as simple as the C code, whether that is simple or not.

Reply on news.ycombinator.com