Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Tue, 5 Nov 2024 22:48:28 +0000
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <vge7bt$1o57r$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 05 Nov 2024 23:48:29 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cf8ab2f706c64865e8fbf40d9cba7390";
	logging-data="1840379"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19LgguN5Bdy5Pa8Iw7rP8yq"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ORjAqDRB7X3RnIAyzyxkoi6VDNk=
In-Reply-To: <vgd6jh$1hmjc$1@dont-email.me>
Content-Language: en-GB
Bytes: 4153

On 05/11/2024 13:29, David Brown wrote:
> On 05/11/2024 13:42, Waldek Hebisch wrote:

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

Your example is an improvement on your previous ones. At least it 
attempts to deal with out-of-range conditions!

However there is still the question of providing that return type. If 
'unreachable' is not a special language feature, then this can fail 
either if the language requires the 'return' keyword, or 'unreachable' 
doesn't yield a compatible type (even if it never returns because it's 
an error handler).

Getting that right will satisfy both the language (if it cared more 
about such matters than C apparently does), and the casual reader 
curious about how the function contract is met (that is, supplying that 
promised return int type if or when it returns).

> // 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];
> }
> 
> 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?).

This is a different category of error.

Here's a related example of what I'd class as a language error:

    int a;
    a = (exit(0), &a);

A type mismatch error is usually reported. However, the assignment is 
never done because it never returns from that exit() call.

I expect you wouldn't think much of a compiler that didn't report such 
an error because that code is never executed.

But to me that is little different from running into the end of function 
without the proper provisions for a valid return value.