5 ms·

I recall seeing a presentation of c2rust by Andrei at a conference a while back. It's great to hear that it's making good progress. I'm curious at how good c2

I recall seeing a presentation of c2rust by Andrei at a conference a while back. It's great to hear that it's making good progress. I'm curious at how good c2rust is at producing idiomatic rust code. It seems like that would be difficult and yet very valuable. > we'd love to hear what you want to see translated next. qemu [1] is all in C (probably C89 or "gnu89") and would make an interesting project, IMO. [1] https://github.com/qemu/qemu https://github.com/qemu/qemu

K0nserv 7y ago
I looked for the transpiled source, but I couldn't find it. I suspect it's not particularly idomatic Rust since it has to maintain all details of the C code however I think it's a very promising project anyway. The fact that they found a memory safety bug is excellent. Maybe translating old C projects to Rust via this method can be used to find memory issues as well as to aid rewriting in Rust projects. EDIT: You can try the transpilation yourself on https://c2rust.com/ https://c2rust.com/ Here's an example of the output: #![allow(dead_code, mutable_transmutes, non_camel_case_types, non_snake_case, non_upper_case_globals, unused_assignments, unused_mut)] #![register_tool(c2rust)] #![feature(register_tool)] #[no_mangle] pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) { let mut i: libc::c_int = 1 as libc::c_int; while i < n { let tmp: libc::c_int = *p.offset(i as isize); let mut j: libc::c_int = i; while j > 0 as libc::c_int && *p.offset((j - 1 as libc::c_int) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1 as libc::c_int) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; }
- steveklabnik 7y ago
  Their plan is twofold, in my understanding: first to translate the code fairly literaly, and then second, to provide unsafe -> safe refactoring tools. As far as I know they’re still on step 1.
  - K0nserv 7y ago
    Cool, that seems like a very sensible approach. The fact that they are already uncovering memory issues in C is promising too.
    - steveklabnik 7y ago
      Yep, I think so too. That example output is more verbose than a human would write, but it’s a sensible start.
  - harpocrates 7y ago
    Step 2 has been happening concurrently, and pretty much since the start of the project. See https://github.com/immunant/c2rust/tree/master/c2rust-refactor https://github.com/immunant/c2rust/tree/master/c2rust-refact.... It is just a lot tougher to get right, so it gets less publicity.
    - steveklabnik 7y ago
      Ah awesome! Thanks for the link.
  - mikepurvis 7y ago
    Looks like it's meant to enable projects similar to how the Go compiler/toolchain was initially translated (with the like-named c2go) and then gradually rewritten over time into idiomatic golang. It's easy to see that this could be a much more tenable project then a grand rewrite that has two codebases iterating forward in parallel for a time.
masklinn 7y ago
> I'm curious at how good c2rust is at producing idiomatic rust code. It’s not. It should eventually improve but currently the goal is to > build a rock-solid translator that gets people up and running in Rust.
- weberc2 7y ago
  What is the ceiling for how good (i.e., "close to generating idiomatic Rust") it could get? Given the differing semantics, it seems like it should be nearly impossible to generate anything close to idiomatic Rust, but I know very little about mechanically translating between programming languages and I would be delighted to be incorrect.
  - masklinn 7y ago
    I'd say "pretty low" on the idiomatic scale, however a very desirable thing would be for them to manage to make most of the generated code not unsafe. Limiting the scope of unsafe would make what would remain easier to convert to safe rust, and then you're off to the refactoring race with much more confidence. A pretty good go would be the ability to recognise wide-spread high-level C patterns and be able to convert them to idiomatic Rust pattern, but even that would be difficult, generally speaking idiomatic C and Rust would likely be structured quite differently, especially on the data(-structure) side.
  - deleted 7y ago
    [deleted]
smolder 7y ago
The long tail of patterns c2rust would need to recognize to reliably make idiomatic code seems like a much larger problem. With that as the goal, it might make sense to build a separate rust-to-rust "idiomaticizer" that can recognize opportunities to reduce code complexity through refactoring, and apply idiomatic patterns without changing application behavior.
- PudgePacket 7y ago
  Clippy already sort is is that, though it seems to target smaller scope idiomatic changes. It's a much harder problem for a tool to recognise the design patterns C pushes you towards and refactor that to something more native to Rust.
- bluejekyll 7y ago
  Maybe. Though there might be lowish hanging fruit that could potentially recognize arrays that could be translated to slices, and heap based allocations using pointer traversal that could be converted to Vec instead. The real issue with doing that isn’t imo, going to Rust, it’s understanding what still needs to be addressable in C. For example, a self-contained application has no external ABI dependencies, and so could assume everything that references that slice must only need to be Rust. A library on the other-hand might still need to present a C ABI.
- harpocrates 7y ago
  As I've already posted elsewhere on this thread, such a tool has been developed in parallel (and with the intent to consume the output of) c2rust. Development on that occurs here: https://github.com/immunant/c2rust/tree/master/c2rust-refactor https://github.com/immunant/c2rust/tree/master/c2rust-refact....
  - smolder 7y ago
    Thanks, I hadn't seen this by the time I posted. Very cool.
flohofwoe 7y ago
Here's an example from another code base, the Linux (GLX+X11+GL) extract of an 3D API wrapper around OpenGL: https://github.com/not-fl3/miniquad/blob/c2rust/sokol-app-sys/src/sokol_app_linux.rs https://github.com/not-fl3/miniquad/blob/c2rust/sokol-app-sy... The generated code looks fairly straightforward, however I wouldn't call it "idiomatic". What's exciting though is that (at least) both Rust and Zig get this ability to translate C code into the "native" language (and sometimes even finding bugs in the process). This basically turns C into a "meta-language" to create "bedrock" cross-platform API modules for a variety of modern languages, essentially the next step from "C as a cross-platform assembler". And to be honest, this sort of "boring" low-level system API glue code which mainly talks to native C system APIs anyway isn't a joy to write in any language, and also doesn't benefit much from more modern language features, can just as well do it in C once, and then "transpile everywhere".
- dodobirdlord 7y ago
  This seems pretty contrary to the purpose of Rust, since the generated code is full of non-idiomatic unsafe and possibly situationally unsound pointer manipulations that could definitely be done in idiomatic safe code. No reason I can see not to just write this sort of thing in Rust to begin with and expose it to other languages via the C ABI to call with FFI or even co-compile with other LLVM languages.
  - flohofwoe 7y ago
    Yeah theoretically, but then you have the same problem as using C libraries from Rust, the build process for those other languages suddenly becomes much more complicated because they must integrate with another language toolchain. Lets say I want to expose a Zig library to Rust or vice versa, now I must call the Zig compiler from Cargo, or Cargo from the Zig build process. With a transpiled library such a project is "clean", it only needs the Rust or Zig toolchain. The transpiling process only needs to happen once, and this can happen automatically on a CI service when the base library is updated and then made available automatically through the language's package repository. Rust probably won't get the ability to transpile to Zig, and Zig probably won't be able to transpile to Rust. Some sort of Lingua Franca makes sense in a multi-language world, and C (or even a subset of C) makes sense for that because it already is the Lingua France, and has a very small feature set to consider. I'm aware that this is a controversial opinion though ;)
ZiiS 7y ago
I would highly value something which turned code into idiomatic code; I don't care which language.
- misterdata 7y ago
  Although not automatic, I find Rust's clippy to be very good at suggesting improvements to code that compiles but simply is not written the way it should.

K0nserv 7y ago

I looked for the transpiled source, but I couldn't find it. I suspect it's not particularly idomatic Rust since it has to maintain all details of the C code however I think it's a very promising project anyway. The fact that they found a memory safety bug is excellent. Maybe translating old C projects to Rust via this method can be used to find memory issues as well as to aid rewriting in Rust projects. EDIT: You can try the transpilation yourself on https://c2rust.com/ https://c2rust.com/ Here's an example of the output: #![allow(dead_code, mutable_transmutes, non_camel_case_types, non_snake_case, non_upper_case_globals, unused_assignments, unused_mut)] #![register_tool(c2rust)] #![feature(register_tool)] #[no_mangle] pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) { let mut i: libc::c_int = 1 as libc::c_int; while i < n { let tmp: libc::c_int = *p.offset(i as isize); let mut j: libc::c_int = i; while j > 0 as libc::c_int && *p.offset((j - 1 as libc::c_int) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1 as libc::c_int) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; }

steveklabnik 7y ago
Their plan is twofold, in my understanding: first to translate the code fairly literaly, and then second, to provide unsafe -> safe refactoring tools. As far as I know they’re still on step 1.
- K0nserv 7y ago
  Cool, that seems like a very sensible approach. The fact that they are already uncovering memory issues in C is promising too.
  - steveklabnik 7y ago
    Yep, I think so too. That example output is more verbose than a human would write, but it’s a sensible start.
- harpocrates 7y ago
  Step 2 has been happening concurrently, and pretty much since the start of the project. See https://github.com/immunant/c2rust/tree/master/c2rust-refactor https://github.com/immunant/c2rust/tree/master/c2rust-refact.... It is just a lot tougher to get right, so it gets less publicity.
  - steveklabnik 7y ago
    Ah awesome! Thanks for the link.
- mikepurvis 7y ago
  Looks like it's meant to enable projects similar to how the Go compiler/toolchain was initially translated (with the like-named c2go) and then gradually rewritten over time into idiomatic golang. It's easy to see that this could be a much more tenable project then a grand rewrite that has two codebases iterating forward in parallel for a time.

masklinn 7y ago

> I'm curious at how good c2rust is at producing idiomatic rust code. It’s not. It should eventually improve but currently the goal is to > build a rock-solid translator that gets people up and running in Rust.

weberc2 7y ago
What is the ceiling for how good (i.e., "close to generating idiomatic Rust") it could get? Given the differing semantics, it seems like it should be nearly impossible to generate anything close to idiomatic Rust, but I know very little about mechanically translating between programming languages and I would be delighted to be incorrect.
- masklinn 7y ago
  I'd say "pretty low" on the idiomatic scale, however a very desirable thing would be for them to manage to make most of the generated code not unsafe. Limiting the scope of unsafe would make what would remain easier to convert to safe rust, and then you're off to the refactoring race with much more confidence. A pretty good go would be the ability to recognise wide-spread high-level C patterns and be able to convert them to idiomatic Rust pattern, but even that would be difficult, generally speaking idiomatic C and Rust would likely be structured quite differently, especially on the data(-structure) side.
- deleted 7y ago
  [deleted]

smolder 7y ago

The long tail of patterns c2rust would need to recognize to reliably make idiomatic code seems like a much larger problem. With that as the goal, it might make sense to build a separate rust-to-rust "idiomaticizer" that can recognize opportunities to reduce code complexity through refactoring, and apply idiomatic patterns without changing application behavior.

PudgePacket 7y ago
Clippy already sort is is that, though it seems to target smaller scope idiomatic changes. It's a much harder problem for a tool to recognise the design patterns C pushes you towards and refactor that to something more native to Rust.
bluejekyll 7y ago
Maybe. Though there might be lowish hanging fruit that could potentially recognize arrays that could be translated to slices, and heap based allocations using pointer traversal that could be converted to Vec instead. The real issue with doing that isn’t imo, going to Rust, it’s understanding what still needs to be addressable in C. For example, a self-contained application has no external ABI dependencies, and so could assume everything that references that slice must only need to be Rust. A library on the other-hand might still need to present a C ABI.
harpocrates 7y ago
As I've already posted elsewhere on this thread, such a tool has been developed in parallel (and with the intent to consume the output of) c2rust. Development on that occurs here: https://github.com/immunant/c2rust/tree/master/c2rust-refactor https://github.com/immunant/c2rust/tree/master/c2rust-refact....
- smolder 7y ago
  Thanks, I hadn't seen this by the time I posted. Very cool.

flohofwoe 7y ago

Here's an example from another code base, the Linux (GLX+X11+GL) extract of an 3D API wrapper around OpenGL: https://github.com/not-fl3/miniquad/blob/c2rust/sokol-app-sys/src/sokol_app_linux.rs https://github.com/not-fl3/miniquad/blob/c2rust/sokol-app-sy... The generated code looks fairly straightforward, however I wouldn't call it "idiomatic". What's exciting though is that (at least) both Rust and Zig get this ability to translate C code into the "native" language (and sometimes even finding bugs in the process). This basically turns C into a "meta-language" to create "bedrock" cross-platform API modules for a variety of modern languages, essentially the next step from "C as a cross-platform assembler". And to be honest, this sort of "boring" low-level system API glue code which mainly talks to native C system APIs anyway isn't a joy to write in any language, and also doesn't benefit much from more modern language features, can just as well do it in C once, and then "transpile everywhere".

dodobirdlord 7y ago
This seems pretty contrary to the purpose of Rust, since the generated code is full of non-idiomatic unsafe and possibly situationally unsound pointer manipulations that could definitely be done in idiomatic safe code. No reason I can see not to just write this sort of thing in Rust to begin with and expose it to other languages via the C ABI to call with FFI or even co-compile with other LLVM languages.
- flohofwoe 7y ago
  Yeah theoretically, but then you have the same problem as using C libraries from Rust, the build process for those other languages suddenly becomes much more complicated because they must integrate with another language toolchain. Lets say I want to expose a Zig library to Rust or vice versa, now I must call the Zig compiler from Cargo, or Cargo from the Zig build process. With a transpiled library such a project is "clean", it only needs the Rust or Zig toolchain. The transpiling process only needs to happen once, and this can happen automatically on a CI service when the base library is updated and then made available automatically through the language's package repository. Rust probably won't get the ability to transpile to Zig, and Zig probably won't be able to transpile to Rust. Some sort of Lingua Franca makes sense in a multi-language world, and C (or even a subset of C) makes sense for that because it already is the Lingua France, and has a very small feature set to consider. I'm aware that this is a controversial opinion though ;)

ZiiS 7y ago

I would highly value something which turned code into idiomatic code; I don't care which language.

misterdata 7y ago
Although not automatic, I find Rust's clippy to be very good at suggesting improvements to code that compiles but simply is not written the way it should.