Re: naked switches

From	Manfred <noname@add.invalid>
Newsgroups	comp.lang.c
Subject	Re: naked switches
Date	2021-07-09 15:35 +0200
Organization	Aioe.org NNTP Server
Message-ID	<sc9jam$1ahh$1@gioia.aioe.org> (permalink)
References	(3 earlier) <31342574-cb69-4ad6-8576-387dcf9caf70n@googlegroups.com> <sc76v8$8ah$1@dont-email.me> <sc7aeg$10u$1@dont-email.me> <sc8von$8fo$1@dont-email.me> <sc979l$n65$1@dont-email.me>

Show all headers | View raw

On 7/9/2021 12:09 PM, Bart wrote:
> On 09/07/2021 09:01, David Brown wrote:
>> On 08/07/2021 18:51, Bart wrote:
>>> On 08/07/2021 16:52, David Brown wrote:
[...]
>>>    It is not something I have seen on other compilers, and I've used
>>>> quite a large number over the years for far smaller and slower devices
>>>> than you are describing here.
>>>>
>>>> The way you handle this with gcc has already been covered - you use
>>>> __builtin_unreachable() to tell the compiler how to optimise for "this
>>>> can't happen" cases.  clang supports __builtin_unreachable() too, and
>>>> MSVC has "__assume(false)" that has the same effect.
>>>>
>>>
>>> How would that work in that case? There doesn't appear to be a bit of
>>> code to hang that onto, unless you specifically create an empty block
>>> for the purpose, guarded by the same sort of range check you want to 
>>> avoid.
>>
>> The normal situation would be :
>>
>>     switch (x) {
>>         case 1 : handle1(); break;
>>         case 2 : handle2(); break;
>>         case 4 : handle4(); break;
>>         default : __builtin_unreachable();    // gcc
>>         default : __assume(0);            // msvc
>>     }
> 
> As I said, you may want to reserve default: for x==3.
> 
>>
>>
>>
>> If you want to say x == 3 is a "do nothing" situation, but you want to
>> tell the compiler it doesn't need to check for x < 1 or x > 4, then you
>> do so simply and clearly:
>>
>>     if ((x < 1) || (x > 4)) __builtin_unreachable();    // gcc
>>     __assume((x >= 1) && (x <= 4));                // msvc
> 
> This is really ugly and may involve some compilers (eg. mine) adding all 
> those extra checks.
> 

__builtin_unreachable() is a GCC extension (and similarly __assume() for 
msvc) that is supposed to have no meaning other than for GCC. And that 
meaning is an instruction for the compiler to consider that range for 
'x' impossible to happen, and optimize accordingly - not to add any 
extra check.
The fact that your compiler may interpret this instruction differently 
is irrelevant because, well, this is a GCC-specific extension - in fact 
your compiler should just /refuse/ to compile the code because 
__builtin_unreachable() should be undefined in your implementation.

Ugliness is an intentional feature of implementation-specific extensions.

> But also, how would this work in practice? Case values are usually 
> enums, you'd need to go and find which are the minimum and maximum 
> enums, and hope they don't change.
> 
> However, if you know that x is always going to have a value of one of 
> those enums, and all enum cases are checked (no gaps), then uswitch will 
> be safe.
> 
> Gaps could be allowed, except for the danger that the gaps could be at 
> either end (so for enums of 1,2,3,4,5, it may omit 1 and/or 5, but it 
> will then assume 2-5 or 1-4).
> 

Extensions of this kind, that go beyond the scope of the core language, 
are not required to feature compact and elegant code - these are 
requirements for the core language. I think it is OK to have to get 
through some coding gymnastics if you want to interact with 
implementation deepnesses of your specific compiler.
If you use them a lot in your current project, macros are the usual 
solution of course.

>>
>>     switch (x) {
>>         case 1 : handle1(); break;
>>         case 2 : handle2(); break;
>>         case 4 : handle4(); break;
>>     }
>>
>>
>> Compare that to someone looking at "uswitch" and wondering what that
>> might possibly mean,
> 
> 
> Unchecked or unsafe. But no worse than scratching their head over 
> __builtin_unreachable and wondering what it has to do with that switch 
> further down the function.
> 

The topic is about a customized variant of some language construct, for 
which you need specific compiler support - whatever compiler you use, 
you need to know it in detail, and __builtin_unreachable is part of the 
game if you use GCC.

Thread

naked switches Robert Finch <robfi680@gmail.com> - 2021-07-07 16:39 -0700
  Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 01:26 +0100
  Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 01:57 +0000
    Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-08 09:16 +0200
  Re: naked switches Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-08 01:00 -0700
    Re: naked switches Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-08 03:25 -0700
      Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 06:58 -0700
        Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 15:52 +0100
        Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-08 17:52 +0200
          Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 17:51 +0100
            Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:01 +0200
              Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 11:09 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 13:14 +0200
                Re: naked switches Manfred <noname@add.invalid> - 2021-07-09 15:35 +0200
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 16:51 +0200
                Re: naked switches Manfred <noname@add.invalid> - 2021-07-09 18:23 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 16:07 +0100
                Re: naked switches Manfred <noname@add.invalid> - 2021-07-09 18:41 +0200
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 11:02 +0200
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 19:20 +0200
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-09 10:46 -0700
                Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-09 19:56 +0000
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 22:01 +0100
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-09 15:07 -0700
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 23:30 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 12:17 +0200
          Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 10:18 -0700
            Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 18:43 +0100
              Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 15:32 -0700
            Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 17:47 +0000
              Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 15:45 -0700
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:27 +0200
                Re: naked switches Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-09 11:13 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 13:30 +0200
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:39 -0700
                Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-11 14:06 +0000
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-11 08:01 -0700
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-16 03:53 -0700
                Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-16 14:47 +0000
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 06:09 -0700
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-09-30 07:03 -0700
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 13:44 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 13:28 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-10 13:04 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 15:39 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-10 15:08 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 17:34 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-10 17:47 +0100
              Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:57 -0700
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-16 03:51 -0700
        Re: naked switches Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-08 11:40 -0700
          Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:38 +0200
  Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 17:33 +0000
    Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-08 17:47 +0000
      Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 17:58 +0000
        Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-08 19:13 +0000
          Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-09 02:30 +0000
        Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:41 +0200
  Re: naked switches Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-30 18:04 +0200

csiph-web