Thou shalt have no other gods before the ANSI C standard 1578

Douglas A. Gwyn

I agree that correctness is not a new requirement. And there is plenty of material on the limits of the techniques for correctness, whether from old-timers or youngsters. From what I can see, the published literature appears to be pretty consistent on this: defect rates on the order of 2-5 defects-KLoC are doing reasonably well for large commercial systems. (It seems that NASA sometimes gets this down to ~ 0.5 defects-KLoC by spending exorbitant amounts of money, but this is not really an option for the rest of us.) That's what we have to work with, if we go by the evidence available to us.

And when even a single buffer overrun is enough to render software insecure -- as is true in most applications written in C today -- that defect rate is too high.

So while correctness might not be a new requirement, there seems to be evidence that the old methods are not up to the task of preventing all buffer overruns, and there doesn't seem to be much evidence to the contrary that anyone can point to. I don't see any evidence that the old-timers have a silver bullet for this problem. Everyone arguing to the contrary on this thread seems mostly guessing, or unable or unwilling to back up their claims with hard evidence.

Yes, we need to change way that developers build systems. That change needs to occur at all levels. We need to change the way we design systems, if we want them to be secure. (This is perhaps the very most important thing we can do.) We need to change how programmers write code. (Also very important, as Gwyn has correctly pointed out.) We need to change how we select languages, libraries, and programming environments. (And yes, for many applications, this might need to include ditching C and-or the C standard library, as much as some C advocates might protest.) We need to change the processes we use for ensuring and measuring quality. The list goes on: We need change at all layers. Current methods aren't getting the job done.