5 ms·

C is doing fine and doesn't need interference. If people want modern C they are better off using other programming languages, and leave the rest of us with gia

by rwmj 3y ago

C is doing fine and doesn't need interference. If people want modern C they are better off using other programming languages, and leave the rest of us with giant C codebases alone without creating pointless make-work.

saagarjha 3y ago
What are your thoughts on efforts to rewrite your giant C codebase in Rust? Most of the people who hold this opinion also seem to dislike people coming near their code with a new language. Improvements from C are generally driven from a pragmatic viewpoint that there is lots of legacy code that is not being well served by C but cannot afford to be rewritten just yet.
- rwmj 3y ago
  We've incrementally replaced C objects with OCaml in one project, still linking everything into one final binary. The two languages (or indeed C and Rust, or C and Golang) interoperate fine. You don't need to rewrite the entire project in one go.
uecker 3y ago
I think if C does not evolve, some people with giant C codebases will find themselves in the unfortunate position that they suddenly will be shut out of a market by regulators, because the C code is considered a risk, or that they will be liable for bugs caused by preventable memory safety issue, and keeping the code will not be sustainable.
- rwmj 3y ago
  That's not really the case. For example Airbus has a giant codebase all written in C. It's never going to be rewritten. Instead they apply many tools to it including formals proofs (of both the code and the toolchain). They work closely with the relevant regulators. I'm actually more confident in that process than I would be of some insane plan to rewrite it all in Rust - which would take forever and Rust doesn't have any of the tooling, formally proven compilers, a language specification, more than one implementation, etc etc. People really don't know what they're talking about when they claim C codebases will be rewritten or will "have to be rewritten" because of "regulations", when the regulators are on top of this stuff already.
  - pjmlp 3y ago
    I bet that many C cowboys[0] will rather switch languages than code under the requirements that Airbus has to comply to. [0] - A meme from the days they used to call programming with straightjacket regarding Modula-2 and Object Pascal, in Usenet flamewars.
    - rwmj 3y ago
      I hope the tools and techniques become more widely available, and those which are proprietary are released or reimplemented as open source.
  - uecker 3y ago
    There are tools to make C safe and for some industry use this will work. I also agree that rewriting in Rust is often a mistake. But NSA is already advising against the use of C: https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/ https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic... And the EU is working on new liability rules. Yes, Airbus might be able to get around this. I am more worried about smaller companies or products including open source.
  - steveklabnik 3y ago
    It is true that safe systems require more than just a programming language. However, the Rust compiler has already been qualified for some safety standards, with more on the way, including the things that Airbus does. You're right that "defense in depth," in a sense, is a good thing for safety, and starting with a language that's memory safe by default adds an additional layer in comparison to things that don't. There is already a bill in the US (it's part of a funding bill so it's just a matter of time until it passes) that, after it passes, the DoD is going to be putting out a plan for moving towards memory safety for things purchased by the DoD. Now, as we all know, because this isn't something that will happen overnight, and so there will be signoffs for exceptions, I'm sure, so we'll see what actually comes of it. There is also a similar one in the EU, but I know less about how things work there so I won't say more other than "I know it exists."
- hgs3 3y ago
  Memory bugs are just bugs. They are not particularly interesting bugs nor difficult to track down. Even if regulators hold vendors responsible for their bugs, memory bugs aren't the only type of bug nor are they the only mechanism for security breaches. Vendors should already be doing their do-diligence to catch bugs by writing a thorough test suite, fuzzing and static analysis. With C they only have one extra step and that is to run their thorough test suite against sanitizers.
  - uecker 3y ago
    Memory bugs very often allow exploitation which is not always the case for other types bugs. Although it is of course true that other types of bugs can also be serious, memory safety violations tend to be more serious if security is a requirement. Fuzzing with sanitizers is not currently able to detect all memory bugs.
hgs3 3y ago
I agree. Lua, Lisp, C - they are all conceptually simple languages that have stood the test of time. Let languages like C++ be the "everything" language and leave C alone.

by rwmj 3y ago

saagarjha 3y ago

What are your thoughts on efforts to rewrite your giant C codebase in Rust? Most of the people who hold this opinion also seem to dislike people coming near their code with a new language. Improvements from C are generally driven from a pragmatic viewpoint that there is lots of legacy code that is not being well served by C but cannot afford to be rewritten just yet.

rwmj 3y ago
We've incrementally replaced C objects with OCaml in one project, still linking everything into one final binary. The two languages (or indeed C and Rust, or C and Golang) interoperate fine. You don't need to rewrite the entire project in one go.

uecker 3y ago

I think if C does not evolve, some people with giant C codebases will find themselves in the unfortunate position that they suddenly will be shut out of a market by regulators, because the C code is considered a risk, or that they will be liable for bugs caused by preventable memory safety issue, and keeping the code will not be sustainable.

rwmj 3y ago
That's not really the case. For example Airbus has a giant codebase all written in C. It's never going to be rewritten. Instead they apply many tools to it including formals proofs (of both the code and the toolchain). They work closely with the relevant regulators. I'm actually more confident in that process than I would be of some insane plan to rewrite it all in Rust - which would take forever and Rust doesn't have any of the tooling, formally proven compilers, a language specification, more than one implementation, etc etc. People really don't know what they're talking about when they claim C codebases will be rewritten or will "have to be rewritten" because of "regulations", when the regulators are on top of this stuff already.
- pjmlp 3y ago
  I bet that many C cowboys[0] will rather switch languages than code under the requirements that Airbus has to comply to. [0] - A meme from the days they used to call programming with straightjacket regarding Modula-2 and Object Pascal, in Usenet flamewars.
  - rwmj 3y ago
    I hope the tools and techniques become more widely available, and those which are proprietary are released or reimplemented as open source.
- uecker 3y ago
  There are tools to make C safe and for some industry use this will work. I also agree that rewriting in Rust is often a mistake. But NSA is already advising against the use of C: https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/ https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic... And the EU is working on new liability rules. Yes, Airbus might be able to get around this. I am more worried about smaller companies or products including open source.
- steveklabnik 3y ago
  It is true that safe systems require more than just a programming language. However, the Rust compiler has already been qualified for some safety standards, with more on the way, including the things that Airbus does. You're right that "defense in depth," in a sense, is a good thing for safety, and starting with a language that's memory safe by default adds an additional layer in comparison to things that don't. There is already a bill in the US (it's part of a funding bill so it's just a matter of time until it passes) that, after it passes, the DoD is going to be putting out a plan for moving towards memory safety for things purchased by the DoD. Now, as we all know, because this isn't something that will happen overnight, and so there will be signoffs for exceptions, I'm sure, so we'll see what actually comes of it. There is also a similar one in the EU, but I know less about how things work there so I won't say more other than "I know it exists."
hgs3 3y ago
Memory bugs are just bugs. They are not particularly interesting bugs nor difficult to track down. Even if regulators hold vendors responsible for their bugs, memory bugs aren't the only type of bug nor are they the only mechanism for security breaches. Vendors should already be doing their do-diligence to catch bugs by writing a thorough test suite, fuzzing and static analysis. With C they only have one extra step and that is to run their thorough test suite against sanitizers.
- uecker 3y ago
  Memory bugs very often allow exploitation which is not always the case for other types bugs. Although it is of course true that other types of bugs can also be serious, memory safety violations tend to be more serious if security is a requirement. Fuzzing with sanitizers is not currently able to detect all memory bugs.

hgs3 3y ago

I agree. Lua, Lisp, C - they are all conceptually simple languages that have stood the test of time. Let languages like C++ be the "everything" language and leave C alone.