6 ms·

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US

by runjake 9mo ago

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US government recently called on everyone to stop using them and move to memory-safe languages. Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those. Edit: Typos and to make the point that I'm not necessarily defending C, just acknowledging it's place. I haven't written a significant amount of C in over 2 decades, probably, aside from microcontroller C.

titzer 9mo ago
C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its uses but it will fuck you up if you do not use industrial-grade PPE. Stop using C if you can. Stop arguing other people should use it. There have always been alternatives and the opportunity cost of ecosystems continuing to invest in C has massive externalized costs for the entire industry and society as a whole.
- coliveira 9mo ago
  Stop spreading FUD.
- Koshkin 9mo ago
  > in exactly the same way C is not known to the state of California to cause cancer.
  - rascul 9mo ago
    Not yet
- toxik 9mo ago
  Asbestos causes mesothelioma and gruesome death. C does not. Be serious.
  - em3rgent0rdr 9mo ago
    When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.
    - lelanthran 9mo ago
      > When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death. And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language. If it was as bad as you make out, we'd have many many many occurrences of this starting in the 80s. We don't.
      - wewtyflakes 9mo ago
        https://en.wikipedia.org/wiki/Therac-25#Root_causes https://en.wikipedia.org/wiki/Therac-25#Root_causes
        torstenvl 9mo ago
        Please don't post flamebait or FUD here. The Therac-25 was not programmed in C.
        wewtyflakes 9mo ago
        How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!). Though, even allowing the "well ackuacally" cop-out argument, it is trivial to find examples of code in C causing failures due to out-of-bounds usage of memory; these bugs are found constantly (and reported here, on HN!). Now, you would need to argue, "well _none_ of those programs are used in life-saving tech" or "well _none_ of those failures would, could, or did cause injury", to which I call shenanigans. The link drop was meant to do just that.
- torstenvl 9mo ago
  HN is not for flamebait.
irishcoffee 9mo ago
> The US government recently called on everyone to stop using them and move to memory-safe languages. The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al. Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop. Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that. Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.
- monocasa 9mo ago
  https://blog.pictor.us/rust-is-do-178-certifiable/ https://blog.pictor.us/rust-is-do-178-certifiable/
  - irishcoffee 9mo ago
    > While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process. I think your link agrees with me, actually.
    - steveklabnik 9mo ago
      https://ferrocene.dev/ https://ferrocene.dev/ DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.
      - irishcoffee 9mo ago
        I believe is may come, that would be really neat. Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.
samiv 9mo ago
Now imagine if every CVE was actually fixed. How would the three letter agencies then spy on people and deliver their payloads on various target devices? The governments around the world really need the security holes to exist despite what they say.
baranul 9mo ago
But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows. For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equally viable choices. And if we are talking about something that needs to be outright safety-critical, Ada and SPARK should definitely be in the debate. However, all of that doesn't override the right of projects to decide on what language they believe is best for them or what strategies concerning safety that they wish to pursue.
- riku_iki 9mo ago
  > Golang, etc... who could be discussed and are equally viable choices. Golang is not 100% zero cost close to metal abstraction. You could add Java and .NET too, but they are not replacement for C obviously.
- gf000 9mo ago
  Pushed != interested in/talked about. People really like to mash together a bunch of random individuals into a single actor/agenda. Golang is not playing in the same niche as C/C++/Rust/Zig, but we have had countless memory safe languages that are indeed a good fit for many uses where C was previously used.
  - pjmlp 9mo ago
    Depends on the point of view, for Reversec, it does. https://reversec.com/usb-armory https://reversec.com/usb-armory > In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an Reversec Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors.

by runjake 9mo ago

titzer 9mo ago

C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its uses but it will fuck you up if you do not use industrial-grade PPE. Stop using C if you can. Stop arguing other people should use it. There have always been alternatives and the opportunity cost of ecosystems continuing to invest in C has massive externalized costs for the entire industry and society as a whole.

coliveira 9mo ago
Stop spreading FUD.
Koshkin 9mo ago
> in exactly the same way C is not known to the state of California to cause cancer.
- rascul 9mo ago
  Not yet
toxik 9mo ago
Asbestos causes mesothelioma and gruesome death. C does not. Be serious.
- em3rgent0rdr 9mo ago
  When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.
  - lelanthran 9mo ago
    > When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death. And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language. If it was as bad as you make out, we'd have many many many occurrences of this starting in the 80s. We don't.
    - wewtyflakes 9mo ago
      https://en.wikipedia.org/wiki/Therac-25#Root_causes https://en.wikipedia.org/wiki/Therac-25#Root_causes
      - torstenvl 9mo ago
        Please don't post flamebait or FUD here. The Therac-25 was not programmed in C.
        wewtyflakes 9mo ago
        How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!). Though, even allowing the "well ackuacally" cop-out argument, it is trivial to find examples of code in C causing failures due to out-of-bounds usage of memory; these bugs are found constantly (and reported here, on HN!). Now, you would need to argue, "well _none_ of those programs are used in life-saving tech" or "well _none_ of those failures would, could, or did cause injury", to which I call shenanigans. The link drop was meant to do just that.
torstenvl 9mo ago
HN is not for flamebait.

irishcoffee 9mo ago

> The US government recently called on everyone to stop using them and move to memory-safe languages. The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al. Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop. Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that. Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.

monocasa 9mo ago
https://blog.pictor.us/rust-is-do-178-certifiable/ https://blog.pictor.us/rust-is-do-178-certifiable/
- irishcoffee 9mo ago
  > While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process. I think your link agrees with me, actually.
  - steveklabnik 9mo ago
    https://ferrocene.dev/ https://ferrocene.dev/ DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.
    - irishcoffee 9mo ago
      I believe is may come, that would be really neat. Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.

samiv 9mo ago

Now imagine if every CVE was actually fixed. How would the three letter agencies then spy on people and deliver their payloads on various target devices? The governments around the world really need the security holes to exist despite what they say.

baranul 9mo ago

But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows. For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equally viable choices. And if we are talking about something that needs to be outright safety-critical, Ada and SPARK should definitely be in the debate. However, all of that doesn't override the right of projects to decide on what language they believe is best for them or what strategies concerning safety that they wish to pursue.

riku_iki 9mo ago
> Golang, etc... who could be discussed and are equally viable choices. Golang is not 100% zero cost close to metal abstraction. You could add Java and .NET too, but they are not replacement for C obviously.
gf000 9mo ago
Pushed != interested in/talked about. People really like to mash together a bunch of random individuals into a single actor/agenda. Golang is not playing in the same niche as C/C++/Rust/Zig, but we have had countless memory safe languages that are indeed a good fit for many uses where C was previously used.
- pjmlp 9mo ago
  Depends on the point of view, for Reversec, it does. https://reversec.com/usb-armory https://reversec.com/usb-armory > In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an Reversec Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors.