4 ms·

> The idea of using C in life-critical and mission-critical software is risible as long as the language definition requires it to have gaping security holes,

> The idea of using C in life-critical and mission-critical software is risible as long as the language definition requires it to have gaping security holes, And yet, even though C has been the primary language for safety and life-critical software for decades, with billions of lines of code written to control things where failure results in loss of human life, there has been no significant loss of human life due to the C language. Throughout the 80s, 90s, 2000s and 2010s C has been the primary language used to control industrial machinery that would kill people on software failure, munitions that would kill people on software failure[1], vehicles that would kill people on software failure, medical devices that would kill people on failure ... and out of these billions of deployments, with billions of lines of code, offhand I can think of only one instance where a different language would have prevented 3 deaths. I'm not saying that C is safe, but it is clear from the statistics that the danger is very very highly overrated. There is a much greater danger in rewriting battle-tested systems just for the sake of rewriting. [1] An industry I worked in, btw.

pjmlp 2y ago
So you are well aware that isn't regular C that gets written, rather something that most HN readers would run away from if forced to write such kind of C.
- lelanthran 2y ago
  > So you are well aware that isn't regular C that gets written, rather something that most HN readers would run away from if forced to write such kind of C. I'm not sure what your point is. It isn't always standard C, if that's what you're trying to say. It's usually not a hosted implementation, but sometimes it is. It's usually done within industry regulated guidelines, but not always. The fact is, the "not always" bit matters, because the body of C code controlling actions where human lives matter is so large that there is still a substantial body of standards-compliant C code that doesn't kill people! The claim being made is contrary to the large body of evidence that we have.
  - pjmlp 2y ago
    My point is MISRA, AUTOSAR, DO-178C and plenty of other ones, alongside the industry moving on into hardware memory tagging as the only means to fix C for such kind of security critical systems, short of using something else if possible as suggested by upcoming cybersecurity laws.
    - lelanthran 2y ago
      > My point is MISRA, AUTOSAR, DO-178C and plenty of other ones, alongside the industry moving on into hardware memory tagging as the only means to fix C for such kind of security critical systems, I dunno how relevant that is. The argument was "Irresponsible to use C for critical systems" The counterpoint is "Despite being the primary language for critical systems, negligible failures have been attributed to the language." I'm basically saying this: How do you explain both that severe reaction to using C AND the historically negligible failure rate of the language itself?
      - RealityVoid 2y ago
        > How do you explain both that severe reaction to using C AND the historically negligible failure rate of the language itself? You CAN get from point A to point B by riding a horse, but why would you when cars are a faster alternative? But to the point, many failures have been attributed to the language, most of security bugs stem from the C's lack of memory safety. _Fortunately_ the reason not a whole lot of deaths can be attributed dirrectly to C is the fact that: - The safety critical sw is has multiple redundancies baked in, including at the HW level that would safeguard against fatal outcomes. - Safety critical SW is tested intensley. This proves the "common" cases of usage, but in my experience still fails for long-tail events. - Memory corruption issues would most of the cases "mearly" lead to resets instead of wrong program output. - Thinking about SW that is deployed in large numbers, if we admit that memory corruption issues happen in very special cases ( see 2nd pct) then the sudden appearence of a bug could _very_ easily be bundled as a fluke instead of a bug and we would probably not be able to distinguish the failure leading to death as being attributed to C. (since " it works fine on my machine" in 99.99% of the cases)
medo-bear 2y ago
> I'm not saying that C is safe, but it is clear from the statistics that the danger is very very highly overrated. There is a much greater danger in rewriting battle-tested systems just for the sake of rewriting. From 80->90->00->10->20s reading and writing C seems less and less magical, including for exploit writers. In 10 years exploits might even be written willy-nilly by an LLM. One of the reasons why writing safe and secure code requires thinking few steps into the future.

pjmlp 2y ago

So you are well aware that isn't regular C that gets written, rather something that most HN readers would run away from if forced to write such kind of C.

lelanthran 2y ago
> So you are well aware that isn't regular C that gets written, rather something that most HN readers would run away from if forced to write such kind of C. I'm not sure what your point is. It isn't always standard C, if that's what you're trying to say. It's usually not a hosted implementation, but sometimes it is. It's usually done within industry regulated guidelines, but not always. The fact is, the "not always" bit matters, because the body of C code controlling actions where human lives matter is so large that there is still a substantial body of standards-compliant C code that doesn't kill people! The claim being made is contrary to the large body of evidence that we have.
- pjmlp 2y ago
  My point is MISRA, AUTOSAR, DO-178C and plenty of other ones, alongside the industry moving on into hardware memory tagging as the only means to fix C for such kind of security critical systems, short of using something else if possible as suggested by upcoming cybersecurity laws.
  - lelanthran 2y ago
    > My point is MISRA, AUTOSAR, DO-178C and plenty of other ones, alongside the industry moving on into hardware memory tagging as the only means to fix C for such kind of security critical systems, I dunno how relevant that is. The argument was "Irresponsible to use C for critical systems" The counterpoint is "Despite being the primary language for critical systems, negligible failures have been attributed to the language." I'm basically saying this: How do you explain both that severe reaction to using C AND the historically negligible failure rate of the language itself?
    - RealityVoid 2y ago
      > How do you explain both that severe reaction to using C AND the historically negligible failure rate of the language itself? You CAN get from point A to point B by riding a horse, but why would you when cars are a faster alternative? But to the point, many failures have been attributed to the language, most of security bugs stem from the C's lack of memory safety. _Fortunately_ the reason not a whole lot of deaths can be attributed dirrectly to C is the fact that: - The safety critical sw is has multiple redundancies baked in, including at the HW level that would safeguard against fatal outcomes. - Safety critical SW is tested intensley. This proves the "common" cases of usage, but in my experience still fails for long-tail events. - Memory corruption issues would most of the cases "mearly" lead to resets instead of wrong program output. - Thinking about SW that is deployed in large numbers, if we admit that memory corruption issues happen in very special cases ( see 2nd pct) then the sudden appearence of a bug could _very_ easily be bundled as a fluke instead of a bug and we would probably not be able to distinguish the failure leading to death as being attributed to C. (since " it works fine on my machine" in 99.99% of the cases)

medo-bear 2y ago

> I'm not saying that C is safe, but it is clear from the statistics that the danger is very very highly overrated. There is a much greater danger in rewriting battle-tested systems just for the sake of rewriting. From 80->90->00->10->20s reading and writing C seems less and less magical, including for exploit writers. In 10 years exploits might even be written willy-nilly by an LLM. One of the reasons why writing safe and secure code requires thinking few steps into the future.