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

David Wagner

snip

IME there is a different. Checking invariants requires a run-time evaluation of an expression, typically a predicate, and that evaluation typically requires some non-shippable scaffolding -- a testing harness.

Certifying invariants is an implementation qualification exercise. It says nothing about design defects that might manifest as bugs. (I'm slight;y concerned about the fuzz on the term "bug").

Your buttertion is false. Testing alone can determine that that the answer to the question is "no". Neither testing nor any other process can determine (in the strict sense of prove) that the answer is "yes" except in trivial cases such as the one where the buffer count is always zero.

Your description of the analysis process, AKA desk checking, works on small systems. A small system is one in which the implementation fits into a single head. It is much harder to use on a medium system, which is one for which there is no head large enough to encompbutt the entire implementation, but the design fits into one or more of the available heads. It is almost useless on large systems where even the design does not fit into one head.

"Looking at the source code" kind of implies an understanding what parts of the source are relevant to the question and then considering the effect of the relevant source on the question at hand. But when it becomes infeasible to determine what source is relevant then it is impossible to determine the effect of the relevant source on the question.

The stuff we build these days is far more complicated than most people understand. And the security aspects of those systems grows more quickly that the complexity due to the presence of adversaries who can manipulate the external buttons and levers of the system to create advantages for themselves. An exploit is a sequence of such advantageous manipulations.

For the reasons set forth above. Big systems are not just scaled up versions of little systems. They are much harder to deal with.

Much has been written about the logical organization of software. Megareams are published every year. Little attention has been paid to the physical organization of software see Lakos, previously cited. But almost no attention is ever paid to the human organization of software (the mapping of software development tasks onto the talent available). It is an extremely black art (I use the term black not in the sense of a pigment, but in the sense of an event horizon).

The buttumption that inspection of source code is always fruitful or sufficient rests upon the buttumption that there is a person competent to perform the inspection. On many systems, the majority of never-been-done-before systems, and almost all large systems, there is no such person. Indeed, due to the limited lifespan of humans in many cases it is possible to show that there cannot ever be such a person,

I agree with the basis for your conclusion, but for the reasons given above disagree with the conclusion itself. None of my objections should be interpreted to say that inspection of the source code is worthless. Indeed, IME it is the most important process for developing high quality software and the reason why I lament that fact that reading software is not formally taught.

But reading the source isn't anywhere near sufficient or even adequate. Like democracy it is merely the best we have. But just like voting it should be done without blind faith in its efficacy.

tj3