Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: "RESET"
Date: Wed, 28 May 2025 03:23:10 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <1016o6j$36o7q$1@dont-email.me>
References: <100thgs$v8cm$1@dont-email.me> <m9f71lF5gr0U1@mid.individual.net>
 <jgr63k1c2ddf09mtihlgv7u9u90v6ihfcp@4ax.com> <1016iak$35lml$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 28 May 2025 12:23:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7f426fe14b63144f55aceb62bb3f7a1c";
	logging-data="3367162"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ANH/be+ESUODn1thDyfRT"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:NV2C8vfzFXAT8wCfMxcHU+ST0Qc=
In-Reply-To: <1016iak$35lml$1@dont-email.me>
Content-Language: en-US
Bytes: 3757

On 5/28/2025 1:43 AM, Martin Brown 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.
> 
> Executing each path in the code at least once is a much more tractable problem. 
> McCabes CCI metric will tell you how many test vectors it will take for  a 
> given complexity of code. And it should be done.

But you don't need to execute each *combination* of paths.  All you
have to do is test the code in each branch (and opposing instance).

> A sufficiently high CCI index for a routine also means that such code is highly 
> unlikely to be correct.

Yes.   You want modules to be small and self-contained.  This is the appeal
of OOPS.  Procedural implementations tend to meander around the codebase,
as if they are remembering particular issues as they wander.  Instead,
focusing on a single, well-defined operation -- on a single object -- gives
you a simpler piece of code that is easier to comprehesively test

> I recall one instance on a mainframe (brand withheld to protect the guilty) 
> where a rogue program that ran continuously was slowly using up IO handles 
> repeatedly opening the tracker ball interface each time a new user accessed it 
> (and never letting go).
> 
> One day after a particularly long uptime it completely ran out of IO handles. 
> Guess what the first thing the error handler tried to do?
> 
> Yup! It tried to obtain a new IO handle to report the error!

Of course!  The fault, there, was not taking the handle early on, to be sure
it would be available.  E.g., the difference between allocating dynamic
resources AS IF static -- just to avoid the possibility of them not being
available when needed.  Ooops!

>> The testing campaign will have only scratched the surface when the Sun
>> runs out of hydrogen and goes supernova.  Tomorrow's problem.
> 
> You can't out test every possible combination of events but you can make sure 
> that the code paths when executed in at least one scenario don't do anything 
> horribly bad. A lot of faults can lurk in the rarely used error recovery code 
> that only gets used after something else has gone wrong.
> 
> Ariane 5 was an example of that sort of thing.

Proof that big, well-funded projects doesn't correlate with BETTER
implementations!  When a project gets too big, group think muddies
the details of importance.

> comp.risks is littered with them.