Re: "RESET"

On Tue, 27 May 2025 14:13:02 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

On 5/25/2025 12:33 PM, Joe Gwinn wrote:

Exactly.  I recall a customer wanting us to verify all possible paths
through a bit of air traffic control radar software, about 100,000
lines of plain C.  Roughly one in five executable line was an IF
statement, which is 20,000 IF statements.  So there are 2^20000 =
10^6020 such paths.

>
And probably 99.9% of them are superfluous.
>

[snip]

The problem is that you have no way to know which cases are
irrelevant.  And practical hardware will have many things able to
retain state.

>
Experience teaches you to construct your code so that testability is
enhanced.  Instead of waiting until it seems to be "done" and then
trying to reassure yourself that it works as intended -- usually by
throwing EXPECTED conditions at it and hoping for the expected
results (that's not testing).

It is not usually the expected that causes trouble:  It ain't what you
don't know that matters, it what you know that ain't so that's the
problem.

You need 2^20000 if there are 2^20000 distinct outcomes (leaf nodes) in
your code.  I strongly doubt that to be the case.

So assume only 1000 IF statements, so it's 2^1000 or 10^600 or so.
You'll still run out of lifetime.

The testing campaign will have only scratched the surface when the Sun
runs out of hydrogen and goes supernova.  Tomorrow's problem.

>
How do you test an electronic circuit?  Let's impose an infinite number of
discrete voltages on each of the input signals and verify the correct
outputs for each?  (Do you deliberately verify all ranges of signal values
and frequencies?  Or, just say "operation outside of these conditions is
indeterminate"?)

You do all the tests for required behavior - does it meet stated
requirements.

Then you random probe it for weeks and see what goes Bang!

One form of this is Fuzzing.

.<https://www.usenix.org/conference/usenixsecurity22/presentation/trippel>

Joe