5 ms·
Reading at the transpiled code, theres something that make me a little worried if this becomes a trend. The lost information in the process. I guess if there's
by oscargrouch 5y ago
Reading at the transpiled code, theres something that make me a little worried if this becomes a trend.
The lost information in the process. I guess if there's an AI in the middle, capturing the logical context and later helping into the translation process.
In that way the power of the source code to teach us will still be there.
I understand if some tool that is in C and need a boost in security might use this, but giving the output code is intractable, they would still have to code in C, so this kind of defeat the some of the goals of writing code in a more secure environment.
Its important to understand that security is just one of the axis of a whole that have much more things to consider.
Having said that, maybe there will be a good use for source code in C that needs a safety boost right away in critical places, or use something like this to spot dark corners and fix the code back in C.
Also, great hacking points to whoever did this, as this is fun just because is hacking at its best.
- brundolf 5y agoYou don't get much of a safety boost right away with the auto-translation, because a lot (all?) of it will start out wrapped in unsafe blocks. The idea is to use it as a jumping-off point from which you can gradually migrate more and more code into safety
- oscargrouch 5y agoThat makes sense. But i wonder if two teams creating a port, one straight from the C code and the other with the translation output.. Which one would end first and with the best version.. (Not sure if doing this from the transpiled code is the best option, giving you will miss a lot of otherwise informative context in the original source)
- tialaramex 5y agoIt produces functions which are pub unsafe extern "C" -- which among other effects currently results in effectively wrapping the code in an unsafe block yes. It seems as though the very long term plan is to divide more thoroughly the unsafe function declaration (purpose: To flag to people calling it that they need to be careful) from the unsafe block (purpose: To flag to the compiler that you checked this is OK and so it's fine that the compiler can't tell if it's OK). Today I believe the linter will optionally complain that you didn't clarify, and perhaps in the Rust 2021 edition the compiler will default to rejecting this, then perhaps Rust 2024 will just outlaw it. I expect c2rust will eventually either just shove everything inside unsafe {} blocks as well as inside unsafe functions, or it will mark code as Rust 2018 edition and let you change that when you've written as idiomatic Rust.