4 ms·

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-writte

by devit 8y ago

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.

hyperpape 8y ago
There's a real sense in which, if this were true, we might not need Rust. If we could mechanically translate the Linux kernel to safe Rust, we could prove the Linux kernel safe. If we could prove the Linux kernel safe, that would be a strong argument against a need to translate it to Rust. 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.
- bluejekyll 8y ago
  The major difference would be that future versions would be in safe Rust as well. All code written after that point would be safe. What you say is true for a single point in time, not for the long-term future. But, I would say this is probably infeasible, so theorizing too much about it seems a little wasteful. If the Linux maintainers, Linus et al, suddennly decided to convert to Rust, it would probably done incrementally, module by module. But it’s unlikely to happen given past statements.
  - hyperpape 8y ago
    If we had a standard for safe C that the linux kernel could feasibly meet, then it could be a condition of future changes that it continue to be safe. As you say, it's pretty hypothetical on both fronts--we're not gonna be able to prove that about a C project like the kernel, and they're not gonna rewrite in Rust any time soon.
    - bluejekyll 8y ago
      As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe. The point I’m making is that the mythical “safe C”, would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point? One variation I’ve seen is the idea of “safer C” put forward by DJB, which would remove all undefined behavior as it’s main goal. In any case, people would need to learn something new, and that seems to be a huge barrier for any language.
      - vasili111 8y ago
        What DJB stands for?
        bluejekyll 8y ago
        Sorry, Daniel J Bernstein, a pretty famous (if you follow the space) cryptologist and software engineer.
      - annywhey 8y ago
        Removal of undefined behavior is an explicit goal of Zig, in fact, and I see Zig as a stronger target for automatic C conversion since the semantics are intentionally closer to C. Still possible to trivially footgun, but the compiler tries to catch more edge cases. There's definitely a space for code that can't be borrow checked, at any rate.
      - hyperpape 8y ago
        Makes sense--I agree.
- geofft 8y ago
  That assumes that such a translation is either a binary success/failure, runs at once, and runs for the entire kernel. More likely, such a tool will be used file-by-file and module-by-module, and when it fails, it will either report obvious mistakes (that will then be fixed in the C source, in the same way that e.g. people doing Python 2 to 3 conversions end up fixing bugs in their Python 2 code to prepare it for reliable conversion) or report more complex design mistakes that warrant rethinking an approach from scratch and starting the new implementation in Rust. If that's what happens, then we would not be proving the Linux kernel safe, and we would have a strong argument for having done the translation.
deleted 8y ago
[deleted]
empath75 8y ago
That’s almost certainly impossible, but I bet there would be some value in doing the conversion without wrapping anything in unsafe blocks and letting compiler warnings guide through making it safe.
- steveklabnik 8y ago
  I doubt you’d get that kind of help; the compiler would say “you need an unsafe block here” not “use a reference instead”, for example.
pornel 8y ago
I've tried to do that with my translator: https://gitlab.com/citrus-rs/citrus#readme https://gitlab.com/citrus-rs/citrus#readme Refactoring C to Rust code is hard. It's not enough to derive bits of information function by function. Often you need to re-architect the whole approach, which is a Sufficiently Smart Compiler problem. Until I've tried it I did not fully realize just how much C uses pointers. Pointer soup is everywhere (and hardly any explicit lengths anywhere). In C's type system the concept of ownership doesn't exist. From that angle it's "dynamically typed". Converting "any pointer can have any ownership, it's implicit from usage" to Rust's "all ownership is statically known" is as hard as converting JavaScript's use of types to a statically-typed language.
- vanderZwan 8y ago
  Wouldn't it be simpler to do a C-to-Rust translator that produces Rust code that does not actually have to compile? Basically one-to-one but with errors in Rust because it's unsafe, and then let the programmers deal with the error codes. That still sounds like a valuable tool since it would take some parts of the boilerplate out of the equation.

by devit 8y ago

hyperpape 8y ago

There's a real sense in which, if this were true, we might not need Rust. If we could mechanically translate the Linux kernel to safe Rust, we could prove the Linux kernel safe. If we could prove the Linux kernel safe, that would be a strong argument against a need to translate it to Rust. 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.

bluejekyll 8y ago
The major difference would be that future versions would be in safe Rust as well. All code written after that point would be safe. What you say is true for a single point in time, not for the long-term future. But, I would say this is probably infeasible, so theorizing too much about it seems a little wasteful. If the Linux maintainers, Linus et al, suddennly decided to convert to Rust, it would probably done incrementally, module by module. But it’s unlikely to happen given past statements.
- hyperpape 8y ago
  If we had a standard for safe C that the linux kernel could feasibly meet, then it could be a condition of future changes that it continue to be safe. As you say, it's pretty hypothetical on both fronts--we're not gonna be able to prove that about a C project like the kernel, and they're not gonna rewrite in Rust any time soon.
  - bluejekyll 8y ago
    As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe. The point I’m making is that the mythical “safe C”, would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point? One variation I’ve seen is the idea of “safer C” put forward by DJB, which would remove all undefined behavior as it’s main goal. In any case, people would need to learn something new, and that seems to be a huge barrier for any language.
    - vasili111 8y ago
      What DJB stands for?
      - bluejekyll 8y ago
        Sorry, Daniel J Bernstein, a pretty famous (if you follow the space) cryptologist and software engineer.
    - annywhey 8y ago
      Removal of undefined behavior is an explicit goal of Zig, in fact, and I see Zig as a stronger target for automatic C conversion since the semantics are intentionally closer to C. Still possible to trivially footgun, but the compiler tries to catch more edge cases. There's definitely a space for code that can't be borrow checked, at any rate.
    - hyperpape 8y ago
      Makes sense--I agree.
geofft 8y ago
That assumes that such a translation is either a binary success/failure, runs at once, and runs for the entire kernel. More likely, such a tool will be used file-by-file and module-by-module, and when it fails, it will either report obvious mistakes (that will then be fixed in the C source, in the same way that e.g. people doing Python 2 to 3 conversions end up fixing bugs in their Python 2 code to prepare it for reliable conversion) or report more complex design mistakes that warrant rethinking an approach from scratch and starting the new implementation in Rust. If that's what happens, then we would not be proving the Linux kernel safe, and we would have a strong argument for having done the translation.

deleted 8y ago

[deleted]

empath75 8y ago

That’s almost certainly impossible, but I bet there would be some value in doing the conversion without wrapping anything in unsafe blocks and letting compiler warnings guide through making it safe.

steveklabnik 8y ago
I doubt you’d get that kind of help; the compiler would say “you need an unsafe block here” not “use a reference instead”, for example.

pornel 8y ago

I've tried to do that with my translator: https://gitlab.com/citrus-rs/citrus#readme https://gitlab.com/citrus-rs/citrus#readme Refactoring C to Rust code is hard. It's not enough to derive bits of information function by function. Often you need to re-architect the whole approach, which is a Sufficiently Smart Compiler problem. Until I've tried it I did not fully realize just how much C uses pointers. Pointer soup is everywhere (and hardly any explicit lengths anywhere). In C's type system the concept of ownership doesn't exist. From that angle it's "dynamically typed". Converting "any pointer can have any ownership, it's implicit from usage" to Rust's "all ownership is statically known" is as hard as converting JavaScript's use of types to a statically-typed language.

vanderZwan 8y ago
Wouldn't it be simpler to do a C-to-Rust translator that produces Rust code that does not actually have to compile? Basically one-to-one but with errors in Rust because it's unsafe, and then let the programmers deal with the error codes. That still sounds like a valuable tool since it would take some parts of the boilerplate out of the equation.