3 ms·

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with the translator being too stupid or the language; neither is something I look for in a tool I use.

dbaupp 8y ago
No, all memory accesses in C are unsafe in the keyword-in-Rust sense: `unsafe` indicates that an API can be misused to cause undefined behaviour, contrasting to non-`unsafe` code where any potential undefined behaviours will be caught at compile time or runtime, no matter how incorrect the program/use of the API is. Just like C, it is an incorrect Rust program if undefined behaviour actually happens, meaning all uses of `unsafe` have to actually be safe, but it's up to the programmer to ensure this, with less compiler assistance than in normal Rust. Every single pointer access `*p` or `p[i]` in C has potential for undefined behaviour (e.g. p is NULL, points to an invalid object, or i is out of bounds), and thus the Rust equivalent is surfacing this risk in a more obvious way.
- dbaupp 8y ago
  (It would have been clearer if my original comment said: "The C and the Rust both risk undefined behaviour in the same ways", instead of using an overloaded meaning of unsafe in saying that the C is unsafe.)
gue5t 8y ago
In the context of Rust, unsafe does not mean incorrect or vulnerable to memory unsafety. Unsafe refers to code whose memory safety has not been proven (by the compiler's static analysis based on ownership and lifetimes, given the assumption of correctness of other unsafe code (so you can look at the proof of memory safety of a program as a whole as an inductive tree of proofs, with the leaves being unsafe code like in `std::Vec`, which is subject to formal and practical scrutiny outside of rustc's static analysis). By this definition, all C code has unsafe memory accesses. However, it is possible to define static analyses that can prove memory safety of some portions of C programs, and incorporating such a thing into C2Rust would allow it to generate more safe Rust and less unsafe Rust.

dbaupp 8y ago

No, all memory accesses in C are unsafe in the keyword-in-Rust sense: `unsafe` indicates that an API can be misused to cause undefined behaviour, contrasting to non-`unsafe` code where any potential undefined behaviours will be caught at compile time or runtime, no matter how incorrect the program/use of the API is. Just like C, it is an incorrect Rust program if undefined behaviour actually happens, meaning all uses of `unsafe` have to actually be safe, but it's up to the programmer to ensure this, with less compiler assistance than in normal Rust. Every single pointer access `*p` or `p[i]` in C has potential for undefined behaviour (e.g. p is NULL, points to an invalid object, or i is out of bounds), and thus the Rust equivalent is surfacing this risk in a more obvious way.

dbaupp 8y ago
(It would have been clearer if my original comment said: "The C and the Rust both risk undefined behaviour in the same ways", instead of using an overloaded meaning of unsafe in saying that the C is unsafe.)

gue5t 8y ago

In the context of Rust, unsafe does not mean incorrect or vulnerable to memory unsafety. Unsafe refers to code whose memory safety has not been proven (by the compiler's static analysis based on ownership and lifetimes, given the assumption of correctness of other unsafe code (so you can look at the proof of memory safety of a program as a whole as an inductive tree of proofs, with the leaves being unsafe code like in `std::Vec`, which is subject to formal and practical scrutiny outside of rustc's static analysis). By this definition, all C code has unsafe memory accesses. However, it is possible to define static analyses that can prove memory safety of some portions of C programs, and incorporating such a thing into C2Rust would allow it to generate more safe Rust and less unsafe Rust.