5 ms·

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem wi

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. And that something can lead to disastrous crashes and security vulnerabilities.

abainbridge 8y ago
> The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. That's also true of all the other languages.
yaris 8y ago
Well, I can say the same about Python, Erlang, Lua, in addition to C and C++. I believe C is not worse than these languages, only that C requires different (sometimes very different) skills and discipline.
- pjmlp 8y ago
  Python, Erlang, Lua = Logic Errors C and C++ = Logic Errors + Memory Corruption + UB From this point of view, Σ Logic Errors < Σ (Logic Errors + Memory Corruption + UB)
  - jcelerier 8y ago
    hmmm... In my experience, I have had much less logic errors in C++ than in Python or JS because I tend to try to encode the domain logic into the types as much as possible, so that I can piggyback on the compiler.
    - pjmlp 8y ago
      And how many memory corruption and UB errors did your Python and JS code had?
      - jcelerier 8y ago
        none, but I hardly ever encounter them in C++ too since I always develop in debug mode with sanitizers and debug std containers, so they blow up immediately. In C that's another story...
        pjmlp 8y ago
        So you are part of the 1% audience crowd from CppCon, developing software alone in C++ without any third party binary libs. :)
- vardump 8y ago
  I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. You really have to try to overwrite memory in those languages. Of course you can shoot yourself into foot with stuff like metatables in Lua and Python metaclasses and whatnot. Then again you should see some C macro messes around... Anyways I don't like when people defend C with that age old argument it requires a clever disciplined programmer that never makes mistakes. Because either such programmers don't exist or they're very rare.
  - notacoward 8y ago
    > I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. Fewer defects, or just different (arguably less severe) defects? It's great that you're sure, but evidence would be even better.
    - vardump 8y ago
      Ok, that's a fair point. I don't have the evidence for that. Scripting languages do have their pitfalls. Lua and python can have type mismatches and even typos causing misbehavior, things that usually aren't issues with C. However, you do need significantly less code than in C.
FraKtus 8y ago
Don't you think that with the tools we have now it's easier to control the quality of code produced (Clang memory sanitizers and so on)? I feel more at ease to ship C code today after instrumenting it than a few years ago...
- vardump 8y ago
  Tooling absolutely helps to reduce defects. That's why you use them. That said, sometimes I'm shocked what kind of disasters get past the analyzers. Stakes are higher than ever. It's not just about functional correctness and avoiding crashes anymore. Your code needs to be secure against outside world malicious actions. Getting rid of counterintuitive security vulnerabilities is very, very hard.
  - pjmlp 8y ago
    I would say that is why security conscious developers use them. Sadly we are a very very tiny percentage, as proven by Herb Sutter question to the audience at CppCon (1% of the audience answered positively), and CVE frequent updates.
- pjmlp 8y ago
  Not really, as it is proven almost on daily basis. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corruption https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corr...
  - FraKtus 8y ago
    How do you know that developers working on those used tools such as the Clang Memory Sanitizer?
    - pjmlp 8y ago
      Because many on that list are well known FOSS projects that supposedly have such processes in place, including manual review before accepting patches into mainline, like the Linux kernel being discussed here.
AlotOfReading 8y ago
This is my view as well, from the same industry. However, the quality of the tools available in C to deal with its issues far exceed those in any other language. I would love to drop C from all my systems, but the alternatives simply aren't there.
- pjmlp 8y ago
  The alternatives were there before UNIX took over server room and workstation market. Just imagine how many millions the IT industry and PhD research have spent developing solutions that would improve C's safety, many of them largely ignored by most C developers.
raxxorrax 8y ago
For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already. You can still overwrite memory but it suddenly became much less likely.
- maccard 8y ago
  That only eliminates a certain case of bugs. There are still plenty of foot-shotguns available - memcpy/memset, strlen, gets/puts, printf, any file IO, networking calls, etc.
- vardump 8y ago
  > For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already. Yeah, bare metal systems often don't allocate at all. Although one sin they often do commit is using same buffer for multiple purposes. What could go wrong... Perhaps even more common is allocating a buffer on stack and writing past bounds somehow. Also DMA to/from stack is usually not a great idea... Above things sound dumb, but can easily happen when you build your abstraction layers and use them carelessly.
  - MrBuddyCasino 8y ago
    > DMA to/from stack wait what oh my god

abainbridge 8y ago

> The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. That's also true of all the other languages.

yaris 8y ago

Well, I can say the same about Python, Erlang, Lua, in addition to C and C++. I believe C is not worse than these languages, only that C requires different (sometimes very different) skills and discipline.

pjmlp 8y ago
Python, Erlang, Lua = Logic Errors C and C++ = Logic Errors + Memory Corruption + UB From this point of view, Σ Logic Errors < Σ (Logic Errors + Memory Corruption + UB)
- jcelerier 8y ago
  hmmm... In my experience, I have had much less logic errors in C++ than in Python or JS because I tend to try to encode the domain logic into the types as much as possible, so that I can piggyback on the compiler.
  - pjmlp 8y ago
    And how many memory corruption and UB errors did your Python and JS code had?
    - jcelerier 8y ago
      none, but I hardly ever encounter them in C++ too since I always develop in debug mode with sanitizers and debug std containers, so they blow up immediately. In C that's another story...
      - pjmlp 8y ago
        So you are part of the 1% audience crowd from CppCon, developing software alone in C++ without any third party binary libs. :)
vardump 8y ago
I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. You really have to try to overwrite memory in those languages. Of course you can shoot yourself into foot with stuff like metatables in Lua and Python metaclasses and whatnot. Then again you should see some C macro messes around... Anyways I don't like when people defend C with that age old argument it requires a clever disciplined programmer that never makes mistakes. Because either such programmers don't exist or they're very rare.
- notacoward 8y ago
  > I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. Fewer defects, or just different (arguably less severe) defects? It's great that you're sure, but evidence would be even better.
  - vardump 8y ago
    Ok, that's a fair point. I don't have the evidence for that. Scripting languages do have their pitfalls. Lua and python can have type mismatches and even typos causing misbehavior, things that usually aren't issues with C. However, you do need significantly less code than in C.

FraKtus 8y ago

Don't you think that with the tools we have now it's easier to control the quality of code produced (Clang memory sanitizers and so on)? I feel more at ease to ship C code today after instrumenting it than a few years ago...

vardump 8y ago
Tooling absolutely helps to reduce defects. That's why you use them. That said, sometimes I'm shocked what kind of disasters get past the analyzers. Stakes are higher than ever. It's not just about functional correctness and avoiding crashes anymore. Your code needs to be secure against outside world malicious actions. Getting rid of counterintuitive security vulnerabilities is very, very hard.
- pjmlp 8y ago
  I would say that is why security conscious developers use them. Sadly we are a very very tiny percentage, as proven by Herb Sutter question to the audience at CppCon (1% of the audience answered positively), and CVE frequent updates.
pjmlp 8y ago
Not really, as it is proven almost on daily basis. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corruption https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corr...
- FraKtus 8y ago
  How do you know that developers working on those used tools such as the Clang Memory Sanitizer?
  - pjmlp 8y ago
    Because many on that list are well known FOSS projects that supposedly have such processes in place, including manual review before accepting patches into mainline, like the Linux kernel being discussed here.

AlotOfReading 8y ago

This is my view as well, from the same industry. However, the quality of the tools available in C to deal with its issues far exceed those in any other language. I would love to drop C from all my systems, but the alternatives simply aren't there.

pjmlp 8y ago
The alternatives were there before UNIX took over server room and workstation market. Just imagine how many millions the IT industry and PhD research have spent developing solutions that would improve C's safety, many of them largely ignored by most C developers.

raxxorrax 8y ago

For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already. You can still overwrite memory but it suddenly became much less likely.

maccard 8y ago
That only eliminates a certain case of bugs. There are still plenty of foot-shotguns available - memcpy/memset, strlen, gets/puts, printf, any file IO, networking calls, etc.
vardump 8y ago
> For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already. Yeah, bare metal systems often don't allocate at all. Although one sin they often do commit is using same buffer for multiple purposes. What could go wrong... Perhaps even more common is allocating a buffer on stack and writing past bounds somehow. Also DMA to/from stack is usually not a great idea... Above things sound dumb, but can easily happen when you build your abstraction layers and use them carelessly.
- MrBuddyCasino 8y ago
  > DMA to/from stack wait what oh my god