4 ms·

This tool is there to automate the boring parts of converting codebases. The real work is verifying the parts that rely on undefined behavior. High fidelity an

by samus 4y ago

This tool is there to automate the boring parts of converting codebases. The real work is verifying the parts that rely on undefined behavior. High fidelity and reliability would be a concern if the transpiler is used to regularly sync between C and Rust versions of a same codebase. It's less of a problem for one-off efforts. Those will usually be heavily tested and inspected before the result is trusted. Edit: it would of course be nice to see proper quality control applied, but prototypes have to proof quickly that they are worth the time spent refining them.

kazinator 4y ago
A source-to-source translator is a textbook example of something that is slam-dunk unit testable. There is almost no valid argument against doing it. Note: maybe this project has it in there; I haven't exhaustively looked into every subdirectory. > if the transpiler is used to regularly sync between C and Rust versions of a same codebase How do you know it won't be used that way? Because the maintainers of every C codebase will stop what they are doing in C, and follow the Rust conversion as soon as they hear about it? Even if you use this tool to permanently cut some code base over to Rust, it would be nice there to be some assurance about what it's doing beyond just "the converted code seems to do the same thing". A conversion could be done two or more times even if the C code isn't changing. Say you do the conversion. Then hack on the converted code. A new version of the converter comes out claiming to fix bugs. You might want to re-run it on the original code again, see if anything changed, and merge those changes to the current code stream that already contains modifications. > The real work is verifying the parts that rely on undefined behavior. That is neither here nor there. A construct that is confirmed undefined in C can be translated to the call to a Rust function that makes damons fly out of your nose. And there can be a couple of unit tests confirming this translation strategy. Or else, something else can be done. E.g. let's say the C code relies on wraparound two's complement arithmetic. The translator can oblige and generate code which makes that work (making that translator more helpful than some modern C compilers).
- samus 4y ago
  Tests could verify that the transpiler correctly maps certain C constructs, but that almost doesn't matter. There is a fair chance that the translation won't work anyways if there's too much C sorcery and undefined behavior involved. The idea of continuous two-way synchronisation between codebases is migraine-inducing to begin with. Even though Rust can probably transpiled to C with way less risk of losing fidelity. But I wouldn't be so sure that this always works out the more `unsafe` blocks the Rust version requires. C compilers are not designed to minimize UB after all, and the results can be very surprising. Yes, I hope people are sane enough to eventually commit to a somewhat tidied-up Rust version and to only keep the C version around to conduct software archeology. Of course, this will produce a hard fork of the codebase, and the usual political reasons specific to such efforts apply.

by samus 4y ago

kazinator 4y ago

A source-to-source translator is a textbook example of something that is slam-dunk unit testable. There is almost no valid argument against doing it. Note: maybe this project has it in there; I haven't exhaustively looked into every subdirectory. > if the transpiler is used to regularly sync between C and Rust versions of a same codebase How do you know it won't be used that way? Because the maintainers of every C codebase will stop what they are doing in C, and follow the Rust conversion as soon as they hear about it? Even if you use this tool to permanently cut some code base over to Rust, it would be nice there to be some assurance about what it's doing beyond just "the converted code seems to do the same thing". A conversion could be done two or more times even if the C code isn't changing. Say you do the conversion. Then hack on the converted code. A new version of the converter comes out claiming to fix bugs. You might want to re-run it on the original code again, see if anything changed, and merge those changes to the current code stream that already contains modifications. > The real work is verifying the parts that rely on undefined behavior. That is neither here nor there. A construct that is confirmed undefined in C can be translated to the call to a Rust function that makes damons fly out of your nose. And there can be a couple of unit tests confirming this translation strategy. Or else, something else can be done. E.g. let's say the C code relies on wraparound two's complement arithmetic. The translator can oblige and generate code which makes that work (making that translator more helpful than some modern C compilers).

samus 4y ago
Tests could verify that the transpiler correctly maps certain C constructs, but that almost doesn't matter. There is a fair chance that the translation won't work anyways if there's too much C sorcery and undefined behavior involved. The idea of continuous two-way synchronisation between codebases is migraine-inducing to begin with. Even though Rust can probably transpiled to C with way less risk of losing fidelity. But I wouldn't be so sure that this always works out the more `unsafe` blocks the Rust version requires. C compilers are not designed to minimize UB after all, and the results can be very surprising. Yes, I hope people are sane enough to eventually commit to a somewhat tidied-up Rust version and to only keep the C version around to conduct software archeology. Of course, this will produce a hard fork of the codebase, and the usual political reasons specific to such efforts apply.