4 ms·

Maybe / maybe not. It's relatively easy to translate C to unsafe Rust, which is a mostly automatic process. The hard part is taking that unsafe C/Rust and turn

Maybe / maybe not. It's relatively easy to translate C to unsafe Rust, which is a mostly automatic process. The hard part is taking that unsafe C/Rust and turning it into checked/safe code. For this part, Rust has many benefits over C: - As a language it is easier to refactor. This is due to a more hygenic macro system, a lack of header files, etc. - The safe subset of Rust is much larger and more expressive than the subset of checked C. This provides more options for the unsafe -> safe translation effort. - The safe subset of Rust is more powerful than the subset of checked C. This means that it's more likely that a piece of code can be translated 1:1 into safe Rust, compared to a more complex transformation. For example, code which returns a pointer into one of its arguments is not uncommon in C, and this can be directly translated into Rust lifetime annotations.

miffy900 5y ago
> Maybe / maybe not. It's relatively easy to translate C to unsafe Rust, which is a mostly automatic process. This makes no sense; extending C code with Checked-C would still be easier as with Checked-C you wouldn't do any translation at all; it's a superset of C, in the same way that TypeScript is to JavaScript.
- Diggsey 5y ago
  First, we're talking about "Transitioning an existing C codebase to checked C". If you're just adding new checked C code, then you're not doing that. Second, you can't just add checked C to a codebase, because you have to actually interop with the unchecked C code, which uses different pointer types. My argument is that it may be easier to do an automatic migration to unsafe Rust, and then incrementally convert to safe Rust, than it would be to leave the codebase as C and try to incrementally convert it to checked C, because the "incremental conversion to checked C" is extremely difficult.
  - naasking 5y ago
    If you read the abstract of the linked paper, you'd see they assert that the annotated pointers can be safely erased, thus making them ordinary pointers again.

miffy900 5y ago

> Maybe / maybe not. It's relatively easy to translate C to unsafe Rust, which is a mostly automatic process. This makes no sense; extending C code with Checked-C would still be easier as with Checked-C you wouldn't do any translation at all; it's a superset of C, in the same way that TypeScript is to JavaScript.

Diggsey 5y ago
First, we're talking about "Transitioning an existing C codebase to checked C". If you're just adding new checked C code, then you're not doing that. Second, you can't just add checked C to a codebase, because you have to actually interop with the unchecked C code, which uses different pointer types. My argument is that it may be easier to do an automatic migration to unsafe Rust, and then incrementally convert to safe Rust, than it would be to leave the codebase as C and try to incrementally convert it to checked C, because the "incremental conversion to checked C" is extremely difficult.
- naasking 5y ago
  If you read the abstract of the linked paper, you'd see they assert that the annotated pointers can be safely erased, thus making them ordinary pointers again.