4 ms·

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

by xvilka 7y ago

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 https://c2rust.com [2] https://github.com/immunant/c2rust https://github.com/immunant/c2rust [3] https://immunant.com/blog/2019/11/rust2020/ https://immunant.com/blog/2019/11/rust2020/

sansnomme 7y ago
A lot of established C codebases are really preprocessor heavy. E.g. https://github.com/remacs/remacs https://github.com/remacs/remacs
- nerpderp82 7y ago
  Compile C to Wasm and run in a Rust hosted Wasm sandbox.
  - pjmlp 7y ago
    Including the Heartbleed version of OpenSSL if one so desires.
Animats 7y ago
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.
- dataking 7y ago
  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.
- mucholove 7y ago
  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 :)
  - z92 7y ago
    I thought Erlang VM was written in Erlang, maybe the first few versions where written in C.
    - filmor 7y ago
      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.
  - kettro 7y ago
    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!
- 7y ago
mister_hn 7y ago
Do you know if there's a "rust2c" tool?
- monocasa 7y ago
  mrustc can compile Rust to C.
  - nickpsecurity 7y ago
    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.
    - monocasa 7y ago
      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.

by xvilka 7y ago

sansnomme 7y ago

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

nerpderp82 7y ago
Compile C to Wasm and run in a Rust hosted Wasm sandbox.
- pjmlp 7y ago
  Including the Heartbleed version of OpenSSL if one so desires.

Animats 7y ago

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.

dataking 7y ago
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.
mucholove 7y ago
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 :)
- z92 7y ago
  I thought Erlang VM was written in Erlang, maybe the first few versions where written in C.
  - filmor 7y ago
    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.
- kettro 7y ago
  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!
7y ago

mister_hn 7y ago

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

monocasa 7y ago
mrustc can compile Rust to C.
- nickpsecurity 7y ago
  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.
  - monocasa 7y ago
    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.