Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!nntp.comgw.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: Tue, 5 Nov 2024 19:39:21 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vgds97$2r682$1@paganini.bofh.team>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>   <vg2llt$38ons$1@dont-email.me> <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org> <b681ee05856e165c26a5c29bf42a8d9d53843d6d@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>
Injection-Date: Tue, 5 Nov 2024 19:39:21 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2988290"; 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: 5463
Lines: 106

David Brown <david.brown@hesbynett.no> wrote:
> On 05/11/2024 13:42, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>>
>>> Then we disagree on what 'multi-way' select might mean. I think it means
>>> branching, even if notionally, on one-of-N possible code paths.
>> 
>> OK.
> 
> I appreciate this is what Bart means by that phrase, but I don't agree 
> with it.  I'm not sure if that is covered by "OK" or not!

You may prefer your own definition, but Bart's is resonable one.
 
>>   
>>> The whole construct may or may not return a value. If it does, then one
>>> of the N paths must be a default path.
>> 
>> 
>> You need to cover all input values.  This is possible when there
>> is reasonably small number of possibilities.  For example, switch on
>> char variable which covers all possible values does not need default
>> path.  Default is needed only when number of possibilities is too
>> large to explicitely give all of them.  And some languages allow
>> ranges, so that you may be able to cover all values with small
>> number of ranges.
>> 
> 
> I think this is all very dependent on what you mean by "all input values".
> 
> Supposing I declare this function:
> 
> // Return the integer square root of numbers between 0 and 10
> int small_int_sqrt(int x);
> 
> 
> To me, the range of "all input values" is integers from 0 to 10.  I 
> could implement it as :
> 
> int small_int_sqrt(int x) {
>        if (x == 0) return 0;
>        if (x < 4) return 1;
>        if (x < 9) return 2;
>        if (x < 16) return 3;
>        unreachable();
> }
> 
> If the user asks for small_int_sqrt(-10) or small_int_sqrt(20), that's 
> /their/ fault and /their/ problem.  I said nothing about what would 
> happen in those cases.
> 
> But some people seem to feel that "all input values" means every 
> possible value of the input types, and thus that a function like this 
> should return a value even when there is no correct value in and no 
> correct value out.

Well, some languages treat types more seriously than C.  In Pascal
type of your input would be 0..10 and all input values would be
handled.  Sure, when domain is too complicated to express in type
than it could be documented restriction.  Still, it makes sense to
signal error if value goes outside handled rage, so in a sense all
values of input type are handled: either you get valid answer or
clear error.

> This is, IMHO, just nonsense and misunderstands the contract between 
> function writers and function users.
> 
> Further, I am confident that these people are quite happen to write code 
> like :
> 
> // Take a pointer to an array of two ints, add them, and return the sum
> int sum_two_ints(const int * p) {
>        return p[0] + p[1];
> }

I do not think that people wanting strong type checking are happy
with C.  Simply, either they use different language or use C
without bitching, but aware of its limitations.  I certainly would
be quite unhappy with code above.  It is possible that I would still
use it as a compromise (say if it was desirable to have single
prototype but handle points in spaces of various dimensions),
but my first attempt would be something like:

typedef struct {int p[2];} two_int;
.....

> Perhaps, in a mistaken belief that it makes the code "safe", they will add :
> 
>        if (!p) return 0;
> 
> at the start of the function.  But they will not check that "p" actually 
> points to an array of two ints (how could they?), nor will they check 
> for integer overflow (and what would they do if it happened?).

I am certainly unhappy with overflow handling in current hardware
an by extention with overflow handling in C.

> 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.

-- 
                              Waldek Hebisch