News for hackers. Stuff that matters.
Re:Let’s Stop Bashing C by steveklabnik on Saturday December 03, 2016 @04:56PM (#13097708)
> I just don't believe you for one minute.

The author demonstrated this by pointing to a list of CVEs caused by their code, so.

Re:Let’s Stop Bashing C by ekidd on Tuesday December 06, 2016 @05:26PM (#13118846)
Not technically my code, and that's the part I don't know how to fix. I used every security technique I knew of back then, including extensive unit tests, manual auditing, malloc debuggers (including Electric Fence), and pretty much every open source tool that was well-known in 2000. I'm sure a modern fuzzer could find some errors, particularly integer overflows, because this was 32-bit code and I didn't understand some modern exploitation tricks.

But as hard as I tried, I still failed, because I relied on 3rd-party code (by an extremely talented programmer), and he made mistakes. Perfection is not a scalable strategy.

Re:Let’s Stop Bashing C by ArkyBeagle on Saturday December 03, 2016 @07:39PM (#13098218)
I understand that completely. "Doing it wrong" is simply a choice that has been made.
Re:Let’s Stop Bashing C by MaulingMonkey on Tuesday December 06, 2016 @02:24PM (#13117484)
To err is human. Beyond the scope of simple, small, toy programs - "doing it wrong" is not a choice, it is a statistic.

You do have choices to make in terms of techniques and tools you can apply (assuming you're aware of them) to modify the statistics, but you will not be perfect in your application of them, and the tools were not written by perfect people either.

There's another choice here - how high you set the security bar for "deals with hostile data off the network". Ekidd chose to set this bar high enough to rule out C. How high do you set it?