2 ms·

The programmers have changed, the machines have changed, the literature has changed, the compilers have changed a lot. You can still write and run the old insec

by Y_Y 2y ago

The programmers have changed, the machines have changed, the literature has changed, the compilers have changed a lot. You can still write and run the old insecure code, but you'll get warnings and hit stack canaries and your colleagues will gasp at you and your merge requests will be rejected.

pjmlp 2y ago
Meaningless changes, as proven by the CVE database, or the kernel corruption by a bad pointer caused by Crowdstrike.
- Y_Y 2y ago
  I respectfully disagree. GP claimed that nothing has changed [regarding string and array security bugs in C] in 50 years. I responded that many relevant factors have changed, such that people tend to write different code now which is less susceptible to those bugs. Of course the same old bugs are possible, and sometimes good coders will still write them. Still I argue that there has been meaningful change since there are more protections against writing bugs in the first place, less incentive to write dangerous code, and more security for when (some) bugs still appear.
  - pjmlp 2y ago
    ISO C89 is exactly like ISO C23 in that regard. CVE database proves that those kind of errors keep coming up in 2024, regardless of those changes. Not only do they keep coming up, the monetary cost of fixing those issues has raised up to a level that now even governments are looking into this.
    - Y_Y 2y ago
      You've made three true statements, but I don't agree if you're implying that they prove that "nothing has changed". Bugs still appear, but they are significantly less common (per project or line not per year) and not as damaging when they occur. This is a non-trivial change for the better in the realm of C application quality. There are more slaves in the world now than ever before in history, but global society has still made great progress on eliminating it in the last thousand years.
    - RavSS 2y ago
      >ISO C89 Not that it matters, but isn't that technically ANSI C(89)? If I remember correctly, the first ISO C standard is instead C90, which is basically identical to C89.
Avamander 2y ago
All that has changed but we still got the libcue code execution bug. I could not find an open-source static analyzer (including -analyzer) that would actually pick up the flaw before someone tries to exploit it. And that's a simple example. We can't tame the dragon C is, empirically nobody can.

by Y_Y 2y ago

pjmlp 2y ago

Meaningless changes, as proven by the CVE database, or the kernel corruption by a bad pointer caused by Crowdstrike.

Y_Y 2y ago
I respectfully disagree. GP claimed that nothing has changed [regarding string and array security bugs in C] in 50 years. I responded that many relevant factors have changed, such that people tend to write different code now which is less susceptible to those bugs. Of course the same old bugs are possible, and sometimes good coders will still write them. Still I argue that there has been meaningful change since there are more protections against writing bugs in the first place, less incentive to write dangerous code, and more security for when (some) bugs still appear.
- pjmlp 2y ago
  ISO C89 is exactly like ISO C23 in that regard. CVE database proves that those kind of errors keep coming up in 2024, regardless of those changes. Not only do they keep coming up, the monetary cost of fixing those issues has raised up to a level that now even governments are looking into this.
  - Y_Y 2y ago
    You've made three true statements, but I don't agree if you're implying that they prove that "nothing has changed". Bugs still appear, but they are significantly less common (per project or line not per year) and not as damaging when they occur. This is a non-trivial change for the better in the realm of C application quality. There are more slaves in the world now than ever before in history, but global society has still made great progress on eliminating it in the last thousand years.
  - RavSS 2y ago
    >ISO C89 Not that it matters, but isn't that technically ANSI C(89)? If I remember correctly, the first ISO C standard is instead C90, which is basically identical to C89.

Avamander 2y ago

All that has changed but we still got the libcue code execution bug. I could not find an open-source static analyzer (including -analyzer) that would actually pick up the flaw before someone tries to exploit it. And that's a simple example. We can't tame the dragon C is, empirically nobody can.