5 ms·

Couldn't one pre process all of these unsafe c things with additional overflow checks and just crash. Let the cpu branch thingy do the optimizations

kstrauser 2y ago
So all we’d have to do is convince C programmers to use a slightly slower libsafec because it’s demonstrably true that no one can use the current language safely? Seems easy enough! But really, no, one could, but one won’t. It’d be easier to convince everyone to switch to Rust than to a safer C.
- uecker 2y ago
  Safety in C improves dramatically with good tooling and coding practice and you can slowly move to safer C without much pain. People who really do not care will also create problems with Rust.
  - AlotOfReading 2y ago
    We've discussed this before. The issue is the same that it's always been. A single mistake anywhere in your codebase means that all language invariants are no longer upheld. No tooling can statically guarantee defined behavior, only catch some of the easier cases. I work in a codebase where we do all of that high powered static analysis and I still regularly find issues with simple tools like ubsan (which isn't remotely exhaustive). Any instance of undefined behavior in safe rust is a language or compiler bug. The only things you really need to check are unsafe blocks, which are rare enough to individually review line by line on a regular basis.
    - uecker 2y ago
      I see Rust code with quite a lof of unsafe and sometimes it has bugs, sometimes triggered from preconditions broken outside of the unsafe block. So no, I think it is an oversimplification to pretend that "only a couple of lines need to be reviewed". And then there other safety issues than memory safety. But I think a safe C that has similar guarantees as Rust is quite possible and we can gradually move there.
      - kstrauser 2y ago
        I genuinely don’t think we can move there at all. There are significant cultural issues: as soon as a safe version with bounds checking is 2% slower, a significant chunk of programmers will claim they can’t use it. There’s also the glacial pace of tooling changes, so even if a safer C existed today, it’d be a couple decades before it was commonly used. But frankly, if you’re going through all that trouble, it’s probably worth considering a newer language that fixes those things today. I mentioned Rust as one example, not the end-all solution to all problems. Nim also plays on the same space and it’s quite nice. The broader point is that I believe it’d be easier to start writing new code in a different language that can easily call existing C code.
        uecker 2y ago
        I do not think newer languages are the solution for two reasons: First, all those new languages also have various downsides, and trade-offs, which may make them a less than ideal choice for many applications. Second, there are an incredible amount of existing C code. We will not get rid of C in the next at least 50 years even if we wanted to (not that I want to). Incrementally improving that code is far more useful than adding other languages into the mix.
      - nuancebydefault 2y ago
        You can always wrap C into a higher level language that makes it safe, but why the hassle? That new language might as well be Rust,which is built up from the bottem with safety in mind.
        uecker 2y ago
        Rust has quite a few problems which why I would not want to use it for my projects: High complexity, long compile times, not stable, not standard, supply chain issues, etc.
      - AlotOfReading 2y ago
        I only mentioned undefined behavior. Memory safety is a subset of those issues, but rust's actual promise is eliminating all UB in safe code. In almost all cases for preconditions, that's solvable by better practices that could be identified in a review. It's the same underlying problem as C, but dramatically more manageable. And of course, any C is liable to be misused in C++ where the committee's current position is that the problem is unsolvable.

kstrauser 2y ago

So all we’d have to do is convince C programmers to use a slightly slower libsafec because it’s demonstrably true that no one can use the current language safely? Seems easy enough! But really, no, one could, but one won’t. It’d be easier to convince everyone to switch to Rust than to a safer C.

uecker 2y ago
Safety in C improves dramatically with good tooling and coding practice and you can slowly move to safer C without much pain. People who really do not care will also create problems with Rust.
- AlotOfReading 2y ago
  We've discussed this before. The issue is the same that it's always been. A single mistake anywhere in your codebase means that all language invariants are no longer upheld. No tooling can statically guarantee defined behavior, only catch some of the easier cases. I work in a codebase where we do all of that high powered static analysis and I still regularly find issues with simple tools like ubsan (which isn't remotely exhaustive). Any instance of undefined behavior in safe rust is a language or compiler bug. The only things you really need to check are unsafe blocks, which are rare enough to individually review line by line on a regular basis.
  - uecker 2y ago
    I see Rust code with quite a lof of unsafe and sometimes it has bugs, sometimes triggered from preconditions broken outside of the unsafe block. So no, I think it is an oversimplification to pretend that "only a couple of lines need to be reviewed". And then there other safety issues than memory safety. But I think a safe C that has similar guarantees as Rust is quite possible and we can gradually move there.
    - kstrauser 2y ago
      I genuinely don’t think we can move there at all. There are significant cultural issues: as soon as a safe version with bounds checking is 2% slower, a significant chunk of programmers will claim they can’t use it. There’s also the glacial pace of tooling changes, so even if a safer C existed today, it’d be a couple decades before it was commonly used. But frankly, if you’re going through all that trouble, it’s probably worth considering a newer language that fixes those things today. I mentioned Rust as one example, not the end-all solution to all problems. Nim also plays on the same space and it’s quite nice. The broader point is that I believe it’d be easier to start writing new code in a different language that can easily call existing C code.
      - uecker 2y ago
        I do not think newer languages are the solution for two reasons: First, all those new languages also have various downsides, and trade-offs, which may make them a less than ideal choice for many applications. Second, there are an incredible amount of existing C code. We will not get rid of C in the next at least 50 years even if we wanted to (not that I want to). Incrementally improving that code is far more useful than adding other languages into the mix.
    - nuancebydefault 2y ago
      You can always wrap C into a higher level language that makes it safe, but why the hassle? That new language might as well be Rust,which is built up from the bottem with safety in mind.
      - uecker 2y ago
        Rust has quite a few problems which why I would not want to use it for my projects: High complexity, long compile times, not stable, not standard, supply chain issues, etc.
    - AlotOfReading 2y ago
      I only mentioned undefined behavior. Memory safety is a subset of those issues, but rust's actual promise is eliminating all UB in safe code. In almost all cases for preconditions, that's solvable by better practices that could be identified in a review. It's the same underlying problem as C, but dramatically more manageable. And of course, any C is liable to be misused in C++ where the committee's current position is that the problem is unsolvable.