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 15:03:54 +0000
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vgdc4q$1ikja$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 05 Nov 2024 16:03:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cf8ab2f706c64865e8fbf40d9cba7390";
	logging-data="1659498"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18DqOy5wXisER8A+0ILpwsh"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:pOEQcyIrAiawc7y+ahOi+RC+E7Y=
Content-Language: en-GB
In-Reply-To: <vgd3ro$2pvl4$1@paganini.bofh.team>
Bytes: 3546

On 05/11/2024 12: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.
>   
>> 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.
> 

What's easier to implement in a language: to have a conditional need for 
an 'else' branch, which is dependent on the compiler performing some 
arbitrarily complex levels of analysis on some arbitrarily complex set 
of expressions...

....or to just always require 'else', with a dummy value if necessary?

Even if you went with the first, what happens if the compiler can't 
guarantee that all values of a selector are covered; should it report 
that, or say nothing?

What happens if you do need 'else', but later change things so all bases 
are covered; will the compiler report it as being unnecesary, so that 
you remove it?


Now, C doesn't have such a feature to test out (ie. that is a construct 
with an optional 'else' branch, the whole of which returns a value). The 
nearest is function return values:

   int F(int n) {
       if (n==1) return 10;
       if (n==2) return 20;
   }

Here, neither tcc not gcc report that you might run into the end of the 
function. It will return garbage if called with anything other than 1 or 2.

gcc will say something with enough warning levels (reaches end of 
non-void function). But it will say the same here:

   int F(unsigned char c) {
       if (c<128) return 10;
       if (c>=128) return 20;
   }