31–40 of 50 posts
I wish they revive their refactoring tool - it was abandoned during the toolchain upgrade. Without the tool, converting the code becomes much more tedious.
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…
The date was wrong; sorry, my mistake. The article reflects progress as of early January 2023. We're actively working on the lifting feature and will post a follow-up post once the tooling are sufficiently mature to be tested by the community.
Has anyone put this to serious use? I played around with it at some point when it was fairly new and at that time I was able to transpile the C into Rust just fine, but that didn't help me much. The idea was to be able to use the Rust toolchain to better understand the code, but the resulting Rust code was even less understandable, and also much harder to refactor. In this case I wasn't attempting a rewrite per se, j…
pub fn insertion_sort(n: i32, p: &mut [i32]) {
for i in 1..n as usize {
let tmp = p[i];
let mut j = i;
while j > 0 && p[j - 1] > tmp {
p[j] = p[j - 1];
j -= 1;
}
p[j] = tmp;
}
}
fn main() {
let mut arr1: [i32; 3] = [1, 3, 2];
insertion_sort(3, &mut arr1);
// …
}
(funnily enough, passing in the "original" code without the `unsafe extern "C"` part makes it produce the exact same output as the above)
I took the insertion_sort impl from the bottom of the post and asked gpt4 to rewrite it into idiomatic Rust: pub fn insertion_sort(n: i32, p: &mut [i32]) { for i in 1..n as usize { let tmp = p[i]; let mut j = i; while j > 0 && p[j - 1] > tmp { p[j] = p[j - 1]; j -= 1; } p[j] = tmp; } } fn main() { let mut arr1: [i32; 3] = [1, 3, 2]; insertion_sort(3, &mut arr1); // … } I guess if this actually works, we can translate…
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.
Did I say move it to production? My question was that the generated code would me way more difficult to understand / modify than the original C.
It was implied in your comment.
The point of C2rust is that the artifacts it generates are extremely transient, they don’t get modified they get replaced and if the rustified version is awkward or hard to grok you just get the C version from Git to validate your understanding, because it’s the exact same thing.
Has anyone put this to serious use? I played around with it at some point when it was fairly new and at that time I was able to transpile the C into Rust just fine, but that didn't help me much. The idea was to be able to use the Rust toolchain to better understand the code, but the resulting Rust code was even less understandable, and also much harder to refactor. In this case I wasn't attempting a rewrite per se, j…
I think this is your problem; to my understanding it's not really the point of the project. The resulting code is meant to be something you can gradually refactor, not something that's immediately better or more understandable. Even if a given piece of code is harder to refactor, it's still important on a large pre-existing project to be able to immediately switch over to the new toolchain all at once, without having to manually refactor/rewrite all of the code all at once
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…
Using something like GPT-4 on this problem is promising. It's probably going to be right most of the time, and its errors can be caught by the next phase of the analysis. That's about what you'd get if you put junior programmers on language conversion.
C2rust is really cool, but if you're familiar with writing rust and implement even a trivial C function in there it produces something absolutely terrifying. I really enjoy rust and pray I don't find myself working in a code base someone just ran c2rust against.
Isn’t the point to generate semantically equivalent Rust code from C, so that you can just get it re-compiling under Rust, and then from there you have a working base from which to start rewriting into safer Rust?
- the base unit is the individual C file, which causes structs and symbols to be duplicated across Rust modules
- for loops are translated to while loops with overflowing additions, which is ugly and unnecessary in pretty much every case (this makes sense, semantically, but it could be used only when necessary, not as general strategy)
- variables are declared at the top of the functions (AFAIR)
C2Rust generates code that requires significant refactorings _before_ semantic (C->Rust) translations - as a matter of fact, they had a refactoring tool, but it's been temporarily deprecated.
It's a fantastic tool, but as of now, it requires developers to write their own refactoring tools.
I took the insertion_sort impl from the bottom of the post and asked gpt4 to rewrite it into idiomatic Rust: pub fn insertion_sort(n: i32, p: &mut [i32]) { for i in 1..n as usize { let tmp = p[i]; let mut j = i; while j > 0 && p[j - 1] > tmp { p[j] = p[j - 1]; j -= 1; } p[j] = tmp; } } fn main() { let mut arr1: [i32; 3] = [1, 3, 2]; insertion_sort(3, &mut arr1); // … } I guess if this actually works, we can translate…
Here, who says the idiomatic translation is not .sort()? It should use the stdlib.