8 ms·

> huge existing stock of C code I feel like the amount of effort that has been spent so far to make C safe and fix bugs due to C not being safe is greater than

> huge existing stock of C code I feel like the amount of effort that has been spent so far to make C safe and fix bugs due to C not being safe is greater than the effort that would have been required to rewrite all existing C code into memory safe languages. But I think secretly C programmers don't want memory safety. Dealing with pointers and remembering to malloc and free are part of what makes them feel more skilled/elite than those other programmers who have garbage collection and bounds checking.

rfoo 2y ago
The problem here is people seldomly get paid rewriting existing C code into memory safe lamguages. While once in a while someone would be annoyed enough and pay for a fixing-C effort for a little. Do you have suggestions on how to fix the incentive?
- admax88qqq 2y ago
  I don't think that's the root problem. I think C programmers don't believe C is a problem. New software is started every day on C. There's no excuse for that and no financial incentive to do it. If the engineers actually admitted that C is not a safe languages for shipping software, then we could at the very least freeze the existing code and write everything _new_ in a same language. But we don't. Engineers still go starting brand new greenfield projects in C which is just insane.
  - optymizer 2y ago
    Just because you don't understand it, doesn't mean it's insane. It just means that your view of the world is different from others.
  - rfoo 2y ago
    > then we could at the very least freeze the existing code and write everything _new_ in a same language Sure, if you are willing to help, here's my wishlist: - I wish we can freeze libssh and write everything new in Rust. - I wish we can freeze CPython and write everything new in Rust. - ... Can you do it for free? At work I'm busy maintaining old projects in C++ and writing new ones in Rust. Since I'm not getting paid to rewrite or maintain our dependencies full-time I can't do above. Oh, I'm not paid to initiate an effort to freeze our old projects either. If this sounds too harsh: - I wish we can freeze ZMK [1] and write everything new in Rust (or Zig, though it's not memory safe, whatever). That's about one of my hobbies and I always wanted to do it. [1] https://github.com/zmkfirmware/zmk https://github.com/zmkfirmware/zmk
optymizer 2y ago
It's not that I don't want memory safety or that I feel superior - what I want is to write the fastest possible portable code. That's what C does, and nothing more. Memory management, array bounds checking and a bunch of other 'safe' features have a price that I'm not willing to apply broadly and redudantly to all of my software. I'm going for speed, that's why I'm using a Ferrari. Corolla's are fast and safe - use those, don't lobby for Ferrari to add safety to their cars at the expense of speed. There are hundreds of languages. Use those. Write transpilers for C code for software that shouldn't have been written in C because it had to be safe. That would be a better use of your time.
- tialaramex 2y ago
  But that's not what C does, You've been, at best, misled. What C does is assume that you're willing to sacrifice correctness to make the compiler simpler which is quite different from what you described. In practice this has a negative consequence for performance as well as safety.
  - optymizer 2y ago
    Having written a compiler for a subset of the C99 standard, I'm going to disagree here. Array bounds are not being checked on every array access not because it would make compilers too complex. Correctness is being sacrificed mostly for speed or portability on future CPUs. There are examples of language features that simplify compiler writing, however. For example, type promotion from char to int is a feature that reduces the number of cases one would have to deal with when implementing the type system in a compiler, but it's there because it doesn't sacrifice neither performance nor portability.
    - eru 2y ago
      > Array bounds are not being checked on every array access not because it would make compilers too complex. That might be true, but you could still specify something slightly less exploit heavy than 'undefined behaviour'. Eg you could make out-of-bounds access into implementation defined behaviour.
girvo 2y ago
> But I think secretly C programmers don't want memory safety Having just come out of embedded firmware land: it's not secret, a few members of my team were pretty open about either not caring about or not wanting memory safety. But the added productivity that Nim gave us outweighed their complaints in the end

rfoo 2y ago

The problem here is people seldomly get paid rewriting existing C code into memory safe lamguages. While once in a while someone would be annoyed enough and pay for a fixing-C effort for a little. Do you have suggestions on how to fix the incentive?

admax88qqq 2y ago
I don't think that's the root problem. I think C programmers don't believe C is a problem. New software is started every day on C. There's no excuse for that and no financial incentive to do it. If the engineers actually admitted that C is not a safe languages for shipping software, then we could at the very least freeze the existing code and write everything _new_ in a same language. But we don't. Engineers still go starting brand new greenfield projects in C which is just insane.
- optymizer 2y ago
  Just because you don't understand it, doesn't mean it's insane. It just means that your view of the world is different from others.
- rfoo 2y ago
  > then we could at the very least freeze the existing code and write everything _new_ in a same language Sure, if you are willing to help, here's my wishlist: - I wish we can freeze libssh and write everything new in Rust. - I wish we can freeze CPython and write everything new in Rust. - ... Can you do it for free? At work I'm busy maintaining old projects in C++ and writing new ones in Rust. Since I'm not getting paid to rewrite or maintain our dependencies full-time I can't do above. Oh, I'm not paid to initiate an effort to freeze our old projects either. If this sounds too harsh: - I wish we can freeze ZMK [1] and write everything new in Rust (or Zig, though it's not memory safe, whatever). That's about one of my hobbies and I always wanted to do it. [1] https://github.com/zmkfirmware/zmk https://github.com/zmkfirmware/zmk

optymizer 2y ago

It's not that I don't want memory safety or that I feel superior - what I want is to write the fastest possible portable code. That's what C does, and nothing more. Memory management, array bounds checking and a bunch of other 'safe' features have a price that I'm not willing to apply broadly and redudantly to all of my software. I'm going for speed, that's why I'm using a Ferrari. Corolla's are fast and safe - use those, don't lobby for Ferrari to add safety to their cars at the expense of speed. There are hundreds of languages. Use those. Write transpilers for C code for software that shouldn't have been written in C because it had to be safe. That would be a better use of your time.

tialaramex 2y ago
But that's not what C does, You've been, at best, misled. What C does is assume that you're willing to sacrifice correctness to make the compiler simpler which is quite different from what you described. In practice this has a negative consequence for performance as well as safety.
- optymizer 2y ago
  Having written a compiler for a subset of the C99 standard, I'm going to disagree here. Array bounds are not being checked on every array access not because it would make compilers too complex. Correctness is being sacrificed mostly for speed or portability on future CPUs. There are examples of language features that simplify compiler writing, however. For example, type promotion from char to int is a feature that reduces the number of cases one would have to deal with when implementing the type system in a compiler, but it's there because it doesn't sacrifice neither performance nor portability.
  - eru 2y ago
    > Array bounds are not being checked on every array access not because it would make compilers too complex. That might be true, but you could still specify something slightly less exploit heavy than 'undefined behaviour'. Eg you could make out-of-bounds access into implementation defined behaviour.

girvo 2y ago

> But I think secretly C programmers don't want memory safety Having just come out of embedded firmware land: it's not secret, a few members of my team were pretty open about either not caring about or not wanting memory safety. But the added productivity that Nim gave us outweighed their complaints in the end