21–30 of 50 posts
What problem does c2Rust solve exactly? Isn't it just gonna produce "garbage" rust. Calling c directly is already possible in rust.
Do no know this particular tool but some automated language to language transpilers I saw produce the code one would not be able to comprehend never mind edit if the need comes.
The goal of C2rust is not to provide a usable code base per se, it’s to provide a convenient base for conversion: once the project is in unsafe rust it can be managed entirely via rust tooling and is hopefully a lot easier to finish up than if you keep having to redefine bindings as you move code from C to Rust. C2rust is a springboard, if you move C2rust-Ed code to production you’re doing it very wrong.
Not that it’s a good idea, but I could see a scenario where it would be worthwhile.
DARPA is funding this. Good. They haven't reached inter-procedural static analysis yet, which means they can't solve the big problem: how big is an array? Most of the troubles in C come from that. Whoever creates the array knows how big it is. Everybody else is guessing. A bit of machine learning might help here. If you see void dosomethingwitharray(int arr[], size_t n) {} a good conjecture is that n is the length of…
As an old osdev currently enjoying using rust instead, I would say I wish.
N might be the length of arr. it might also correspond to the number of elements of (implicit) type t that would fit in the unsigned char array arr. It might be the length of the array minus space for a trailing char (either minus one or minus sizeof(char) bytes). Or it could be the size plus one, because why not.
I am very curious to see how this transpiler problems will be handled by gpt4 in the upcoming months.
When it goes wrong, the advice will include "write better comments, so the transpiler knows what you're doing". Proponents will liken this to type-linting comments. Critics will liken this to INTERCAL / p-hacking / tax fraud, and will claim that the transpiler can be mislead by confusing comments. Proponents will show you that GPT-4 can identify misleading comments in the critics' examples. Critics will say "real code won't contain comments like that, so this ability is useless". Proponents will say "oh, yeah, that too I guess". Critics will promptly vanish in a puff of logic.
The manually-written tool will get better: more slowly at first, but more steadily, and with only a few (predictable, fixable) correctness bugs. Eventually, it will be able to correctly process more programs than the leading GPT-4 approach can. It will be months before anyone notices this, since the two camps (manual approach, GPT-4 approach) will not really be talking to each other enough.
Eventually, somebody will write a blog post about a semi-obscure but representative benchmark (perhaps the Linux kernel), pointing out that the manual tool works better now. There will be a brief wave of hype about the "new tool" and the "death of AI". Then some people will fine-tune the model on tricksy cases using the manually-written tool's output, some other people will call that utterly cheating, and the hype will give way to bickering.
Realistic? Well… GPT-4 is proprietary, and we've got more efficient LLM architectures now – but I think the sorts of people to make a tool like this will probably stick with OpenAI's APIs. (It's In The Cloud.™)
Do no know this particular tool but some automated language to language transpilers I saw produce the code one would not be able to comprehend never mind edit if the need comes.
The goal of C2rust is not to provide a usable code base per se, it’s to provide a convenient base for conversion: once the project is in unsafe rust it can be managed entirely via rust tooling and is hopefully a lot easier to finish up than if you keep having to redefine bindings as you move code from C to Rust. C2rust is a springboard, if you move C2rust-Ed code to production you’re doing it very wrong.
Earlier quoted context omitted.
The goal of C2rust is not to provide a usable code base per se, it’s to provide a convenient base for conversion: once the project is in unsafe rust it can be managed entirely via rust tooling and is hopefully a lot easier to finish up than if you keep having to redefine bindings as you move code from C to Rust. C2rust is a springboard, if you move C2rust-Ed code to production you’re doing it very wrong.
On the other hand, if I have some working C dependency which I never intend to modify (owing to its complexity or stability), plopping the autogenerated Rust code simplifies your build step. Not that it’s a good idea, but I could see a scenario where it would be worthwhile.
This is ideal state of affairs but sometimes the reality can interfere with our intents.
DARPA is funding this. Good. They haven't reached inter-procedural static analysis yet, which means they can't solve the big problem: how big is an array? Most of the troubles in C come from that. Whoever creates the array knows how big it is. Everybody else is guessing. A bit of machine learning might help here. If you see void dosomethingwitharray(int arr[], size_t n) {} a good conjecture is that n is the length of…
> a good conjecture is that n is the length of arr As an old osdev currently enjoying using rust instead, I would say I wish . N might be the length of arr. it might also correspond to the number of elements of (implicit) type t that would fit in the unsigned char array arr. It might be the length of the array minus space for a trailing char (either minus one or minus sizeof(char) bytes). Or it could be the size plus…
Earlier quoted context omitted.
On the other hand, if I have some working C dependency which I never intend to modify (owing to its complexity or stability), plopping the autogenerated Rust code simplifies your build step. Not that it’s a good idea, but I could see a scenario where it would be worthwhile.
>"never intend to modify" This is ideal state of affairs but sometimes the reality can interfere with our intents.
DARPA is funding this. Good. They haven't reached inter-procedural static analysis yet, which means they can't solve the big problem: how big is an array? Most of the troubles in C come from that. Whoever creates the array knows how big it is. Everybody else is guessing. A bit of machine learning might help here. If you see void dosomethingwitharray(int arr[], size_t n) {} a good conjecture is that n is the length of…
probably the abi if nothing else?