5 ms·

Wouldn't it make more sense for -fanalyze to work like a rust borrow checker?

AlotOfReading 7y ago
No, because C's memory model is freer than Rust's. E.g. it's perfectly legal for memory to have multiple owners, as long as you respect the rules around accessing and freeing it.
- steveklabnik 7y ago
  This comment is a little confusing, because it's the same as Rust: you have to respect rules around access and freeing, but when you do, multiple owners are fine. Are there specifics you're thinking of here?
  - AlotOfReading 7y ago
    You'd know better than me, but to my knowledge the borrow checker prevents having aliasing mutable references without unsafe (or cell). Leaving aside the merits of actually doing this in real code, it's ultimately something the compiler has to consider. Similarly, is splitting borrows still an issue? I think that'd apply here as well, and has a much more legitimate purpose in real code.
    - steveklabnik 7y ago
      Sure. But UnsafeCell is a part of the language. So if we're comparing the language to the language, then they're equivalent. It's only if you say "no unsafe Rust and no unsafe rust in anything you use" that this wouldn't be true, and that also means any program is effectively impossible (to print something to the screen, you need to talk to the OS, and that's unsafe!) > Similarly, is splitting borrows still an issue? It depends on exactly what you mean, there's a few different patterns that people mean when they mean "splitting borrows" and one of them has a camp of people who don't think that's a problem, but a feature.
- glouwbug 7y ago
  Yes but a static analyzer could enforce _new_ projects to maintain single ownership model, which could push C and its existing tools closer to Rust. A borrow checker for C is totally feasible as it is just compile time analysis of object lifetime. Something like gcc -fborrow-check would prop up C to safe new heights.
  - Gaelan 7y ago
    If you're writing new C, why wouldn't you write C++ or Rust? I think part of why Rust's borrow checker works so well is because its support for higher-level abstraction is so good; my impression is that manual iteration and general array munging is pretty hard to do in Rust (especially without runtime checks), but that doesn't matter because the iterator abstraction is so good. It'd be pretty hard to build something like Rust's iterators in C.
    - glouwbug 7y ago
      C is still prevalent in embedded systems. Something like a clean slate strong type checker to remove C's weak type checking would be greatly appreciated for those who mainly work in IOT where C++ is already treated like C with classes.

No, because C's memory model is freer than Rust's. E.g. it's perfectly legal for memory to have multiple owners, as long as you respect the rules around accessing and freeing it.

steveklabnik 7y ago
This comment is a little confusing, because it's the same as Rust: you have to respect rules around access and freeing, but when you do, multiple owners are fine. Are there specifics you're thinking of here?
- AlotOfReading 7y ago
  You'd know better than me, but to my knowledge the borrow checker prevents having aliasing mutable references without unsafe (or cell). Leaving aside the merits of actually doing this in real code, it's ultimately something the compiler has to consider. Similarly, is splitting borrows still an issue? I think that'd apply here as well, and has a much more legitimate purpose in real code.
  - steveklabnik 7y ago
    Sure. But UnsafeCell is a part of the language. So if we're comparing the language to the language, then they're equivalent. It's only if you say "no unsafe Rust and no unsafe rust in anything you use" that this wouldn't be true, and that also means any program is effectively impossible (to print something to the screen, you need to talk to the OS, and that's unsafe!) > Similarly, is splitting borrows still an issue? It depends on exactly what you mean, there's a few different patterns that people mean when they mean "splitting borrows" and one of them has a camp of people who don't think that's a problem, but a feature.
glouwbug 7y ago
Yes but a static analyzer could enforce _new_ projects to maintain single ownership model, which could push C and its existing tools closer to Rust. A borrow checker for C is totally feasible as it is just compile time analysis of object lifetime. Something like gcc -fborrow-check would prop up C to safe new heights.
- Gaelan 7y ago
  If you're writing new C, why wouldn't you write C++ or Rust? I think part of why Rust's borrow checker works so well is because its support for higher-level abstraction is so good; my impression is that manual iteration and general array munging is pretty hard to do in Rust (especially without runtime checks), but that doesn't matter because the iterator abstraction is so good. It'd be pretty hard to build something like Rust's iterators in C.
  - glouwbug 7y ago
    C is still prevalent in embedded systems. Something like a clean slate strong type checker to remove C's weak type checking would be greatly appreciated for those who mainly work in IOT where C++ is already treated like C with classes.