Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Code guidelines
Date: Wed, 4 Sep 2024 12:47:30 +0200
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <vb9ds3$3q992$1@dont-email.me>
References: <vb6v1t$3b5mb$1@dont-email.me> <vb726n$3b4rq$1@dont-email.me>
 <vb736j$3b5mb$2@dont-email.me> <vb75g9$3bntp$1@dont-email.me>
 <vb77tn$3bu07$3@dont-email.me> <vb7d6l$3d5mv$1@dont-email.me>
 <vb8vcf$3nlvn$1@dont-email.me> <87y147zxve.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 04 Sep 2024 12:47:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0366692407b62e2f3ab0bc1ba1697c81";
	logging-data="4007202"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX186FKVB4hNFg/zrOUB7NL8Y1DyktPkN/Fw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:eGOXHaLt7wgOkGCbB23jm8DncI4=
Content-Language: en-GB
In-Reply-To: <87y147zxve.fsf@nosuchdomain.example.com>
Bytes: 2800

On 04/09/2024 09:22, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Before you put any check in code, think about the circumstances in
>> which it could fail.  If there are no circumstances, it is redundant
>> and counter-productive.
> [...]
> 
> One thing to consider is that if a check can never actually fail the
> recovery code *cannot be tested* (and you can't get 100% code coverage).
> 
>      p = NULL; // assume p is not volatile
>      if (p != NULL) {
>          do_something(); // can never execute this
>      }
> 
> Of course not all such cases are so easily detectible (
> 

I wrote "in almost all cases, it is never tested" - but as you say, in 
some cases it /cannot/ ever be tested because the test conditions can 
never be triggered.

I think, however, that "could be tested, but is not tested" is worse. 
I've seen cases of code that has been put in for extra checks "just to 
make sure" that had not been tested, and caused more trouble.

One case I remember was some extra checks for timeouts in some 
communications.  The new checks were unnecessary - a higher level 
timeout mechanism was already in place, tested, and working.  The new 
checks were never tested, and never triggered during normal operation. 
But when a 32-bit millisecond counter rolled over, the check was wrong 
triggered - and the handling code was buggy and hung.  Thus the 
unnecessary and untested extra check resulted in systems hanging every 
49 days.