Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Taming The Switch-Statement
Date: Fri, 16 Oct 2026 13:12:59 -0700
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <86qzhppfp0.fsf@linuxsc.com>
References: <119qf6l$2rmg3$1@dont-email.me> <119r8u3$34nce$1@dont-email.me> <119rau4$35ugq$1@dont-email.me> <20261005142208.51@kylheku.com> <11a1clv$1dg97$1@kst.eternal-september.org> <11a1hge$1gpor$1@kst.eternal-september.org> <11a26hc$ef4n$2@dont-email.me> <11a2l1i$1rim5$1@kst.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 16 Oct 2026 20:13:02 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="3814047"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8CKXoodBsJQR6sVGOU63HG39xXlfaVlM="; posting-host="6aa7975ca949d05eced06ab246205481"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:sIqixhz1yUz4B+TZIcoIfDbaw4I= sha1:+Wem4hj4iRUZhssS7EBvRPKFmpg= sha256:V2RC1zmpa/v+4Wc+SxWsXG9KRwc9nfNEaFle1wmAxJs= sha1:f+LQcFpvWUwUAzFkvjGvtov3inI= sha256:h+C6deAgwjBPwFboCagrnYortQesqgWB9g9WAv6deU8=
Xref: csiph.com comp.lang.c:403217

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 2026-10-06 03:05, Keith Thompson wrote:
>>
>>> [...]
>>> A weird but mostly harmless consequence of this is that C23 keeps
>>> the syntactic construct of a *labeled-statement*, but it's used
>>> extremely rarely.  Any C17-or-earlier labeled-statement at the
>>> top level of an enclosing compound-statement is no longer a C23
>>> labeled-statement, even though it looks like one.  In C23, a
>>> labeled-statement can only occur in an odd construct like this:
>>>      if (condition)
>>>          LABEL: statement;
>>
>> You've been arguing on the implicit difference in the language
>> definition here.  That's all a fine explanation.
>>
>> What I wonder about is what you find "odd" with that construct.
>> For folks who use jumps and labels (not me) that looks not too
>> odd to me;  I can imagine programming cases where that may be
>> useful.
>
> It's unlikely that I'd write something like that.  If I did,
> I'd use braces:
>
>     if (condition) {
>         LABEL: statement;
>     }
>
> I'm sometimes willing to omit optional braces, but almost exclusively
> in cases where the entire construct is on one line:
>
>     if (condition) statement;

Some years ago I had occasion to write some code that in outline
looked something like this (pseudo code in <>'s):

   <typename>
   some_action( <arguments> ){

      <some setup>

      goto START_LOOP;
      for( ; <test>; <update> ){
         if( <early-exit-test> ) return <something>;
         if( <circumstance> ) START_LOOP: {
            <re-initialization actions>
         }
      }

      <rest of function>
   }

I deliberately put the label START_LOOP before the braces because I
wanted to make it obvious that the target was the whole branch of
the if().  Putting the label inside the braces could give the
mistaken impression that it was just a coincidence that what happens
when the loop starts is the entire body of the if().  Putting the
label before the braces makes it obvious that what the if() is doing
and where the loop is being entered are exactly the same point.

> Aside from that, writing an if statement and providing a way to bypass
> the test feels odd (to me).  Presumably there's a `goto LABEL;`
> elsewere in the same function.  I'd look for a clearer way to structure
> the code.

Indeed, and not only did I look, but I already had looked, and ended
up at the above version only after trying multiple alternatives.  I
judged this variation to be the easiest to understand, because all
the alternatives either were more convoluted or had to duplicate
some code, not only the code in the if() body but also the <update>
clause in the for() statement.