Path: ...!news.nobody.at!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Mon, 11 Nov 2024 19:09:08 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vgtkoi$igod$1@paganini.bofh.team>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>   <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me> <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team> <vgd6jh$1hmjc$1@dont-email.me> <vgds97$2r682$1@paganini.bofh.team> <vgdvfj$1m6ho$1@dont-email.me> <vgplgk$757j$1@paganini.bofh.team> <vgqk1h$edif$2@dont-email.me>
Injection-Date: Mon, 11 Nov 2024 19:09:08 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="606989"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 6542
Lines: 104

David Brown <david.brown@hesbynett.no> wrote:
> On 10/11/2024 07:57, Waldek Hebisch wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 05/11/2024 20:39, Waldek Hebisch wrote:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> On 05/11/2024 13:42, Waldek Hebisch wrote:
>>>>>> Bart <bc@freeuk.com> wrote:
> 
> 
> Type checks can be extremely helpful, and strong typing greatly reduces 
> the errors in released code by catching them early (at compile time). 
> And temporary run-time checks are also helpful during development or 
> debugging.
> 
> But extra run-time checks are costly (and I don't mean just in run-time 
> performance, which is only an issue in a minority of situations).  They 
> mean more code - which means more scope for errors, and more code that 
> must be checked and maintained.  Usually this code can't be tested well 
> in final products - precisely because it is there to handle a situation 
> that never occurs.

It depends.  gcc used to have several accessors macros which could
perform checks.  They were turned of during "production use" (mainly
because checks increased runtime), but were "always" present in
source code.  "Source cost" was moderate, checking code took hundreds,
moje be low thousends of lines in headres definitng the macros.
Actual use of macros was the same as if macros did no checking,
so there was minimal increase in source complexity.

Concerning testing, things exposed in exported interface frequently
can be tested with reasonable effort.  The main issue is generating
apropriate arguments and possibly replicating global state (but
I normally have global state only when strictly necessary).

>>>>> A function should accept all input values - once you have made clear
>>>>> what the acceptable input values can be.  A "default" case is just a
>>>>> short-cut for conveniently handling a wide range of valid input values -
>>>>> it is never a tool for handling /invalid/ input values.
>>>>
>>>> Well, default can signal error which frequently is right handling
>>>> of invalid input values.
>>>>
>>>
>>> Will that somehow fix the bug in the code that calls the function?
>>>
>>> It can be a useful debugging and testing aid, certainly, but it does not
>>> make the code "correct" or "safe" in any sense.
>> 
>> There is concept of "partial correctness": code if it finishes returns
>> correct value.  A variation of this is: code if it finishes without
>> signaling error returns correct values.  Such condition may be
>> much easier to verify than "full correctness" and in many case
>> is almost as useful.  In particular, mathematicians are _very_
>> unhappy when program return incorrect results.  But they are used
>> to programs which can not deliver results, either because of
>> lack or resources or because needed case was not implemented.
>> 
>> When dealing with math formulas there are frequently various
>> restrictions on parameters, like we can only divide by nonzero
>> quantity.  By signaling error when restrictions are not
>> satisfied we ensure that sucessful completition means that
>> restrictions were satisfied.  Of course that alone does not
>> mean that result is correct, but correctness of "general"
>> case is usually _much_ easier to ensure.  In other words,
>> failing restrictions are major source of errors, and signaling
>> errors effectively eliminates it.
>> 
> 
> Yes, out-of-band signalling in some way is a useful way to indicate a 
> problem, and can allow parameter checking without losing the useful 
> results of a function.  This is the principle behind exceptions in many 
> languages - then functions either return normally with correct results, 
> or you have a clearly abnormal situation.
> 
>> In world of prefect programmers, they would check restrictions
>> before calling any function depending on them, or prove that
>> restrictions on arguments to a function imply correctness of
>> calls made by the function.  But world is imperfect and in
>> real world extra runtime checks are quite useful.
>> 
> 
> Runtime checks in a function can be useful if you know the calling code 
> might not be perfect and the function is going to take responsibility 
> for identifying that situation.  Programmers will often be writing both 
> the caller and callee code, and put temporary debugging and test checks 
> wherever it is most convenient.
> 
> But I think being too enthusiastic about putting checks in the wrong 
> place - the callee function - can hide the real problems, or make the 
> callee code writer less careful about getting their part of the code 
> correct.

IME the opposite: not having checks in called function simply delays
moment when error is detected.  Getting errors early helps focus on
tricky problems or misconceptions.  And motivates programmers to
be more careful

Concerning correct place for checks: one could argue that check
should be close to place where the result of check matters, which
frequently is in called function.  And frequently check requires
computation that is done by called function as part of normal
processing, but would be extra code in the caller.

-- 
                              Waldek Hebisch