C2Rust: translate C into Rust code • Hacker News Board

Re: C2Rust: translate C into Rust code

#41

Post by steveklabnik » Sat, Jun 23, 2018, 7:24 PM UTC

empath75 wrote: post #36

devit wrote: post #21

I think the next step would be to have a tool that can convert C into safe Rust with a combination of static analysis and framework/program-specific user-written rules to translate specific C framework constructs into Rust equivalents. An eventual goal could be for instance to automatically translate the Linux kernel with the aid of a lot of custom rules to handle its constructs.

That’s almost certainly impossible, but I bet there would be some value in doing the conversion without wrapping anything in unsafe blocks and letting compiler warnings guide through making it safe.

I doubt you’d get that kind of help; the compiler would say “you need an unsafe block here” not “use a reference instead”, for example.

Re: C2Rust: translate C into Rust code

#42

Post by staticassertion » Sat, Jun 23, 2018, 7:27 PM UTC

smt88 wrote: post #32

wtetzner wrote: post #27

Earlier quoted context omitted.

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.

Re: C2Rust: translate C into Rust code

#43

Post by staticassertion » Sat, Jun 23, 2018, 7:30 PM UTC

Animats wrote: post #24

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 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 trans…

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.

Re: C2Rust: translate C into Rust code

#44

Post by bluejekyll » Sat, Jun 23, 2018, 7:31 PM UTC

hyperpape wrote: post #40

bluejekyll wrote: post #38

Earlier quoted context omitted.

The major difference would be that future versions would be in safe Rust as well. All code written after that point would be safe. What you say is true for a single point in time, not for the long-term future. But, I would say this is probably infeasible, so theorizing too much about it seems a little wasteful. If the Linux maintainers, Linus et al, suddennly decided to convert to Rust, it would probably done increme…

If we had a standard for safe C that the linux kernel could feasibly meet, then it could be a condition of future changes that it continue to be safe. As you say, it's pretty hypothetical on both fronts--we're not gonna be able to prove that about a C project like the kernel, and they're not gonna rewrite in Rust any time soon.

As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe.

The point I’m making is that the mythical “safe C”, would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point?

One variation I’ve seen is the idea of “safer C” put forward by DJB, which would remove all undefined behavior as it’s main goal.

In any case, people would need to learn something new, and that seems to be a huge barrier for any language.

Re: C2Rust: translate C into Rust code

#45

Post by sometimesijust » Sat, Jun 23, 2018, 7:39 PM UTC

This either does not work well OR there is no need for rust to exist. Is there a pressing need for rust code that is as unsafe as c?

Re: C2Rust: translate C into Rust code

#46

Post by masklinn » Sat, Jun 23, 2018, 8:13 PM UTC

sitkack wrote: post #29

masklinn wrote: post #17

Earlier quoted context omitted.

> So the demo does actually translate C into unsafe Rust. It's semantics-preserving, and C constructs are not expected to match safe Rust, so that makes sense, Corrode does more or less the same. Citrus generates "safe rust", it also doesn't generate working code.

The compilation target could be a Rust slab [0], much like Emscripten uses Typed Arrays [1]. In doing so, it would retain much of the safety properties of Rust, but it pushes the problem into maintaining "the heap" for the C code. [0] https://github.com/carllerche/slab [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

That would be significantly less useful if the intent is to move the code from C to Rust.

Re: C2Rust: translate C into Rust code

#47

Post by vasili111 » Sat, Jun 23, 2018, 8:36 PM UTC

bluejekyll wrote: post #44

hyperpape wrote: post #40

Earlier quoted context omitted.

If we had a standard for safe C that the linux kernel could feasibly meet, then it could be a condition of future changes that it continue to be safe. As you say, it's pretty hypothetical on both fronts--we're not gonna be able to prove that about a C project like the kernel, and they're not gonna rewrite in Rust any time soon.

As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe. The point I’m making is that the mythical “safe C”, would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point? One variation I’ve s…

What DJB stands for?

Re: C2Rust: translate C into Rust code

#48

Post by Animats » Sat, Jun 23, 2018, 8:38 PM UTC

staticassertion wrote: post #43

Animats wrote: post #24

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 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 trans…

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…

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

Re: C2Rust: translate C into Rust code

#49

Post by bluejekyll » Sat, Jun 23, 2018, 8:38 PM UTC

vasili111 wrote: post #47

bluejekyll wrote: post #44

Earlier quoted context omitted.

As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe. The point I’m making is that the mythical “safe C”, would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point? One variation I’ve s…

What DJB stands for?

Sorry, Daniel J Bernstein, a pretty famous (if you follow the space) cryptologist and software engineer.

Re: C2Rust: translate C into Rust code

#50

Post by annywhey » Sat, Jun 23, 2018, 8:39 PM UTC

bluejekyll wrote: post #44

hyperpape wrote: post #40

Earlier quoted context omitted.

If we had a standard for safe C that the linux kernel could feasibly meet, then it could be a condition of future changes that it continue to be safe. As you say, it's pretty hypothetical on both fronts--we're not gonna be able to prove that about a C project like the kernel, and they're not gonna rewrite in Rust any time soon.

As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe. The point I’m making is that the mythical “safe C”, would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point? One variation I’ve s…

Removal of undefined behavior is an explicit goal of Zig, in fact, and I see Zig as a stronger target for automatic C conversion since the semantics are intentionally closer to C. Still possible to trivially footgun, but the compiler tries to catch more edge cases.

There's definitely a space for code that can't be borrow checked, at any rate.