21–30 of 79 posts
An eventual goal could be for instance to automatically translate the Linux kernel with the aid of a lot of custom rules to handle its constructs.
Earlier quoted context omitted.
Fortunately, once you start refactoring the Rust to take advantage of the functionality that doesn't exist in C (like slices, iterators, etc), things start to look much cleaner. Translating the code into ugly, unsafe Rust is intended to only be the first step. We're working on tools to help with that refactoring process, too.
Sounds like a case of "writing C in Rust" compared with "writing Rust". You're not really writing in a language until you're thinking in its idioms.
The insertion sort conversion example makes Rust look intimidating and verbose as compared to C :-).
It's also explicitly typing everything, which increases verbosity.
The "clean" rust conversion would look something like this:
fn insertion_sort(p: &mut [T]) {
for i in 1..p.len() {
let x = p[i];
let mut j = i;
while j > 0 && p[j-1] > x {
p[j] = p[j-1];
j -= 1;
}
p[j] = x;
}
}
fn insertion_sort(p: &mut [T]) {
for i in 0..p.len() {
for j in (0..i).rev() {
if p[j] pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int)
-> () {
let mut i: libc::c_int = 1i32;
while i 0i32 && *p.offset((j - 1i32) as isize) > tmp {
*p.offset(j as isize) = *p.offset((j - 1i32) as isize);
j -= 1
}
*p.offset(j as isize) = tmp;
i += 1
};
}
A C++ to Rust translator would be a good thing, but it has to be much smarter than this. This doesn't even comprehend arrays in C.
A good translator might need some human help to deal with C's ambiguities. Like "Is this an array? (Y or N)" How big is it? (Enter expression). Then you get a program that's real Rust. If the user is wrong about the size, safe Rust will either allocate too much space or get a subscript error.
What's the use case for this? Are native C binaries/libraries not invokable in rust?
This is compiling C into very unsafe Rust as a target language: pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) -> () { let mut i: libc::c_int = 1i32; while i 0i32 && *p.offset((j - 1i32) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1i32) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; } The output is unmaintainable, like the output from a compiler. This isn't trans…
The bigger issue I see here is that this should be implemented as an iterator. I don't think there's any hope of automatically converting to those though - there's just no C equivalent except pointer arithmetic.
This is compiling C into very unsafe Rust as a target language: pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) -> () { let mut i: libc::c_int = 1i32; while i 0i32 && *p.offset((j - 1i32) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1i32) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; } The output is unmaintainable, like the output from a compiler. This isn't trans…
The insertion sort conversion example makes Rust look intimidating and verbose as compared to C :-).
Fortunately, once you start refactoring the Rust to take advantage of the functionality that doesn't exist in C (like slices, iterators, etc), things start to look much cleaner. Translating the code into ugly, unsafe Rust is intended to only be the first step. We're working on tools to help with that refactoring process, too.
So the demo does actually translate C into unsafe Rust. I'm guessing this translator is, thus, unaware of Rust borrowing/ownership system?
> So the demo does actually translate C into unsafe Rust. It's semantics-preserving, and C constructs are not expected to match safe Rust, so that makes sense, Corrode does more or less the same. Citrus generates "safe rust", it also doesn't generate working code.
[0] https://github.com/carllerche/slab
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
I think the next step would be to have a tool that can convert C into safe Rust with a combination of static analysis and framework/program-specific user-written rules to translate specific C framework constructs into Rust equivalents. An eventual goal could be for instance to automatically translate the Linux kernel with the aid of a lot of custom rules to handle its constructs.
Note that this point is independent of the question of whether rewriting the Linux kernel in Rust is actually good/feasible idea. I also think that Rust has other advantages over C that aren't just safety, so it's not a complete comparison--safety is just the biggest one.