3 ms·

I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust tra

by wspeirs 11y ago

I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is successfully going from some not-so-obfuscated C code to equally not-so-obfuscated Rust code?

pcwalton 11y ago
> how hard do folks think it would be to make a C -> Rust transpiler? Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.
- wspeirs 11y ago
  I'm not sure it would take "years and years" of static analysis research. You could use the data-flow analysis that is built into LLVM, then punt on the rest. It doesn't HAVE to produce Rust code that compiles 100% of the time. The goal would be to run it through the transpiler so you have a starting place to produce Rust code that compiles and works the same as the original C code. Again, this might be a terrible idea, but I'd be curious to hear from anyone that has experience with this sort of porting...
  - pcwalton 11y ago
    Data flow has nothing to do with the hard problems you'd have to solve.
steveklabnik 11y ago
Generally the opinion is "it might work but it would be terrible Rust," and given that FFI into C has no overhead, replacing things a symbol at a time might be a better approach to this kind of problem.
Manishearth 11y ago
> hard do folks think it would be to make a C -> Rust transpiler Easy. But it won't be too useful. Rust isn't a compiler that magically finds memory errors. Transpiling C code to Rust will not find those memory errors unless you have a really good transpiler that can detect the overall structure and design of the C code. It will just give you a ton of Rust error messages; probably none of which relate to an actual memory error. (Or you transpile to `unsafe` rust, in which case, what was the point?). Rust works with a set of rules, and these rules enforce some things in your programming/software design style. This enforced style (i.e. the discipline around memory usage) is what gets us memory safety. This style is not the same as the style used in programming C/C++; so a dumb transpilation won't work. You need to write a transpiler that can figure out what logic the code (and not just for a function, for a larger unit) was trying to encode, and write that in Rust. That's ... a nontrivial problem to solve with a transpiler, probably requiring AI skills. It's a mostly trivial thing to do as a human, since mostly such "transpilation" involves noticing a few key issues (related to highly-shared structs and whatnot) and fixing them (leaving most of the code the same).

by wspeirs 11y ago

pcwalton 11y ago

> how hard do folks think it would be to make a C -> Rust transpiler? Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.

wspeirs 11y ago
I'm not sure it would take "years and years" of static analysis research. You could use the data-flow analysis that is built into LLVM, then punt on the rest. It doesn't HAVE to produce Rust code that compiles 100% of the time. The goal would be to run it through the transpiler so you have a starting place to produce Rust code that compiles and works the same as the original C code. Again, this might be a terrible idea, but I'd be curious to hear from anyone that has experience with this sort of porting...
- pcwalton 11y ago
  Data flow has nothing to do with the hard problems you'd have to solve.

steveklabnik 11y ago

Generally the opinion is "it might work but it would be terrible Rust," and given that FFI into C has no overhead, replacing things a symbol at a time might be a better approach to this kind of problem.

Manishearth 11y ago

> hard do folks think it would be to make a C -> Rust transpiler Easy. But it won't be too useful. Rust isn't a compiler that magically finds memory errors. Transpiling C code to Rust will not find those memory errors unless you have a really good transpiler that can detect the overall structure and design of the C code. It will just give you a ton of Rust error messages; probably none of which relate to an actual memory error. (Or you transpile to `unsafe` rust, in which case, what was the point?). Rust works with a set of rules, and these rules enforce some things in your programming/software design style. This enforced style (i.e. the discipline around memory usage) is what gets us memory safety. This style is not the same as the style used in programming C/C++; so a dumb transpilation won't work. You need to write a transpiler that can figure out what logic the code (and not just for a function, for a larger unit) was trying to encode, and write that in Rust. That's ... a nontrivial problem to solve with a transpiler, probably requiring AI skills. It's a mostly trivial thing to do as a human, since mostly such "transpilation" involves noticing a few key issues (related to highly-shared structs and whatnot) and fixing them (leaving most of the code the same).