4 ms·

> is it just the compile-time checks about Ownership? Sometimes. There's a lot more to safety than memory safety, but that's the easiest to define. Other aspe

> is it just the compile-time checks about Ownership? Sometimes. There's a lot more to safety than memory safety, but that's the easiest to define. Other aspects might be safety against null values, safety against poor error handling, etc. Those are much harder to define. > Could not the C compiler be given the same thing, with a flag like "strict mode"? Not really, no. There's a lot of research into proving C code safe, and automation of it, and it's not really feasible for general C codebases. There are tons of static analysis tools that try to get part of the way there, but they can be slow, miss things, and have many false positives. It would require, at minimum, some seriously ugly annotations. There are papers that demonstrate such annotation based approaches with C. One that I read ended up looking quite a lot like Rust, at which point, you wonder why you wouldn't just write rust. Not a stupid question at all, by the way. > Couldn't this be added to the C compiler? Rust is able to insert those frees because it has lots of information about memory usage at compile time. C doesn't, therefor C can't insert those frees in the general case. Other issues, cultural ones that is, like "people just disable it" are fair but not the biggest issue imo. But to further emphasize that point there are many runtime mitigation techniques (ASLR, stack cookies), and they get disabled all the time because, and this is the extra sad part, they legitimately find bugs and crash a program that otherwise may have appeared to work, and the fastest "fix" is disabling it. Re: Effort, totally, yes. But the effort isn't really split. There are tons of people working on safer C/C++ through tools like fuzzing, static analysis, and runtime mitigations.

jfkebwjsbx 6y ago
> you wonder why you wouldn't just write rust Because it is another language. If the researchers behind the borrow checker had implemented it on a safe variation of C/C++, then it would have been much easier to push for it in many companies. Something like the Python 2/3 split is better than another completely different language. Don’t get me wrong, Rust brings improvement in other areas too, which is fine, but when we are talking about many-million-LOCs, you don’t care that much. I am still waiting for someone to bring lifetime annotations to C and C++. Those I could use right away. Rust, not so much.
- tgv 6y ago
  But adding rust-like lifetime annotations to a many-million-LOC code base would result in totally bricking the code with 99.99999% certainty. I tried to port an (Earley) parser from C to Rust. It wasn't even a port, but more of a rewrite with similar function structure. The first part worked well, even though I had to resort to an arena (a special type of allocator that can guarantee lifetimes at the expense of freeing them later than strictly possible). Then I tried to get in shared parse trees. It was a nightmare. It could simply not be done with the same efficiency as in C. I had to resort to using array indices instead of pointers, or use ref counting where it wasn't needed. This had quite some impact on the calling functions. And that was a few hundred lines of plain, non-tricky C.
  - jfkebwjsbx 6y ago
    If your C/C++ is sane, then your code was already written with lifetimes in mind and enforcing them is not a big deal. There will be places, no doubt, that you cannot do it, but if you can easily cover 80% of the code, that is way better than nothing and then you can work on redesigning the 20% (perhaps even rewriting it in another language since it has to be changed, for instance to Rust). Same argument as Rust uses for unsafe blocks. There have been specialized annotations for things like mutexes for a while in several projects which help static analyzers prove things too, so it is not new.
- ma2rten 6y ago
  Doesn't unique_ptr in C++ provide that?
  - saagarjha 6y ago
    unique_ptr allows for use-after-move, so it's not perfect.

jfkebwjsbx 6y ago

> you wonder why you wouldn't just write rust Because it is another language. If the researchers behind the borrow checker had implemented it on a safe variation of C/C++, then it would have been much easier to push for it in many companies. Something like the Python 2/3 split is better than another completely different language. Don’t get me wrong, Rust brings improvement in other areas too, which is fine, but when we are talking about many-million-LOCs, you don’t care that much. I am still waiting for someone to bring lifetime annotations to C and C++. Those I could use right away. Rust, not so much.

tgv 6y ago
But adding rust-like lifetime annotations to a many-million-LOC code base would result in totally bricking the code with 99.99999% certainty. I tried to port an (Earley) parser from C to Rust. It wasn't even a port, but more of a rewrite with similar function structure. The first part worked well, even though I had to resort to an arena (a special type of allocator that can guarantee lifetimes at the expense of freeing them later than strictly possible). Then I tried to get in shared parse trees. It was a nightmare. It could simply not be done with the same efficiency as in C. I had to resort to using array indices instead of pointers, or use ref counting where it wasn't needed. This had quite some impact on the calling functions. And that was a few hundred lines of plain, non-tricky C.
- jfkebwjsbx 6y ago
  If your C/C++ is sane, then your code was already written with lifetimes in mind and enforcing them is not a big deal. There will be places, no doubt, that you cannot do it, but if you can easily cover 80% of the code, that is way better than nothing and then you can work on redesigning the 20% (perhaps even rewriting it in another language since it has to be changed, for instance to Rust). Same argument as Rust uses for unsafe blocks. There have been specialized annotations for things like mutexes for a while in several projects which help static analyzers prove things too, so it is not new.
ma2rten 6y ago
Doesn't unique_ptr in C++ provide that?
- saagarjha 6y ago
  unique_ptr allows for use-after-move, so it's not perfect.