Re: else ladders practice

On 22/11/2024 19:10, Kaz Kylheku wrote:

On 2024-11-22, Bart <bc@freeuk.com> wrote:

You also seem proud that in this example:
>
    int F(int n) {
        if (n==1) return 10;
        if (n==2) return 20;
    }
>
You can use 'unreachable()', a new C feature, to silence compiler
messages about running into the end of the function, something I
considered a complete hack.

 Unreachable assertions are actually a bad trade if all you are looking
for is to suppress a diagnostic. Because the behavior is undefined
if the unreachable is actually reached.
 

You should only use "unreachable()" in places where it is /never/ actually reached - thus it is perfectly safe if you use it correctly. (I'm not sure of any features of any language that are safe to use /incorrectly/.)

That's literally the semantic definition! "unreachable()" means,
roughly, "remove all definition of behavior from this spot in the
program".

Yes.  So that's fine, as long as execution never reaches it.  That's the whole point - you are telling the compiler that this thing cannot happen.  Compilers optimise all the time on the basis of what they know can and cannot happen - this just lets the programmer specify it.

 Whereas falling off the end of an int-returning function only
becomes undefined if the caller obtains the return value,
and of course in the case of a void function, it's well-defined.

All true - but so what?

 You are better off with:
    assert(0 && "should not be reached");
   return 0;
 if asserts are turned off with NDEBUG, the function does something that
is locally safe, and offers the possibility of avoiding a disaster.

Asserts - or other temporary checks resulting in stopping the program with a useful message - can be very helpful in debugging.  If you are not entirely sure that code execution can never reach a particular point, then either don't use "unreachable()" there, or if you prefer, put a conditional check there.  "asset" is not magic - you can do the same thing yourself :
#ifdef CHECK_UNREACHABLES
#define Unreachable() \
do { \
printf("Unreachable hit on line %i of file %s\r\n", \
__LINE__, __FILE__); \
exit(1); \
} while (0)
#else
#define Unreachable() unreachable()
#endif
Adjust it to suit your taste.

In released code, hitting a false assertion is a bug in your code that should never happen.  Hitting an "unreachable()" is a bug in your code that should never happen.  Either way, you've screwed up.  And unless you have good reason to believe that the user will actually give you all the critical information you need to duplicate the situation and find the bug, the assert is no better than the unreachable().  It is, however, less efficient and it means you are adding extra code ("return 0;") that is of no use, and is in no way testable.
So to me, unreachable() is better than an assert that is never triggered.  And an assert that /could/ be triggered is not something I would ever want in released code of the kind of program I write (embedded systems).

 The only valid reason for using unreachable is optimization: you're
introducing something unsafe in order to get better machine code. When
the compiler is informed that the behavior is always undefined when some
code is reached, it can just delete that code and everything dominated
by it (reachable only through it).
 

"unreachable()" is not unsafe unless you are using it incorrectly. /Everything/ is unsafe if you are using it incorrectly.

The above function does not need a function return sequence to be
emitted for the fall-through case that is not expected to occur,
if the situation truly does not occur. Then if it does occur, hell
will break loose since control will fall through to whatever bytes
follow the abrupt end of the function.