Hacker News Reader

Comment by Y_Y | Hacker News Reader

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.

View on HN

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

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.

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.

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.

>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.

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.

Reply on news.ycombinator.com