Re: "A diagram of C23 basic types"

On 04/04/2025 04:43, Janis Papanagnou wrote:

On 03.04.2025 13:07, Muttley@DastardlyHQ.org wrote:

On Thu, 3 Apr 2025 11:41:31 +0200
David Brown <david.brown@hesbynett.no> wibbled:

 [ "unreachable()" is now standard. ]
 

I can't tell you what Scott uses it for, but I have used gcc's
__builtin_unreachable() a fair number of times in my coding.  I use it
to inform both the compiler and human readers that a path is unreachable:

>
What for? The compiler doesn't care and a human reader would probably
prefer a meaningful comment if its not obvious. If you're worried about the
code accidently going there use an assert.
>

switch (x) {
case 1 : ...
case 2 : ...
case 3 : ...
default : __builtin_unreachable();
}
>
I can also use it to inform the compiler about data :
>
if ((x < 0) || (x > 10)) __builtin_unreachable();
// x must be 1 .. 10

>
And that'll do what? You want the compiler to compile in a hidden value check?

 I also don't see a point here; myself I'd write some sort of assertion
in such cases, depending on the application case either just temporary
for tests or a static one with sensible handling of the case.
 

It can't be a static assertion, since "x" is unknown at compile time. Dynamic assertions cost - runtime and code space.  That's fine during testing and debugging, or for non-critical code.  But for important code when you know a particular fact will hold true but the compile can't figure it out for itself, you don't want to pay that cost.  You also don't want to have run-time code that is untestable - such as for handling a situation that can never occur.
Usually I wrap my unreachable's in a macro that supports other static testing and optional run-time testing.  But ultimately it often results in more efficient final code.

>

Good use of __builtin_unreachable() can result in smaller and faster
code, and possibly improved static error checking.  It is related to the

>
Sorry, don't see how. If you think a piece of code is unreachable then don't
put it in in the first place!

 Let me give that another spin...
 In cases like above 'switch' code I have the habit to (often) provide
a default branch that contains a fprintf(stderr, "Internal error: ..."
or a similar logging command and some form of exit or trap/catch code.
I want some safety for the cases where in the _evolving_ program bugs
sneak in by an oversight.[*]

I might enable extra checks during testing and debugging.
But if the unreachable() is ever reached, the bug is not in that code - it is in the code that calls it.  A message from that code could conceivably help locate the bugging calling code, in conjunction with a debugger and a call trace.  But I don't want correct code to be weighed down by vague attempts at helping to find flaws in other code - if that were an acceptable way to write the code, I would not be using C in the first place!

 Personally I don't care about a compiler who is clever enough to warn
me, say, about a lacking default branch but not clever enough to notice
that it's intentionally, cannot be reached (say, in context of enums).

enums in C are not guaranteed to be a value from the corresponding enumeration.  The compiler can't assume that "colour_to_hex" will not be called with a value of, say, 42, because the language says it is perfectly reasonable to do that.  (This is different from passing a "bool" parameter - the compiler /can/ assume that the parameter is either 0 or 1.)

I can understand that it might be of use for others, though. (There's
certainly some demand if it's now standard.)

My example was paraphrased from the C23 standard - that /is/ an appropriate and common use of it.
It has existed as a gcc extension for decades, and there is an equivalent in MSVC and many other serious compilers.  It was added to C++ (C++23, IIRC), along with an "assume" attribute that effectively combines a conditional and an unreachable().  Compilers implement "unreachable()" by treating it as undefined behaviour.

 I'm uninformed about __builtin_unreachable(), I don't know whether it
can be overloaded, user-defined, or anything.

It is a gcc (and clang) extension - like all "__builtin" functions or pseudofunctions.  No, it cannot be overloaded or user defined.

If that's not the case
I'd anyway write my own "Internal error: unexpected ..." function to
use that in all such cases for error detection and tracking of bugs.

Sure.  I typically have the call wrapped in a macro with extra features.   But those are a distraction in showing what unreachable() does and why it is useful.

 Janis
 [*] This habit is actually a very old one and most probably resulting
from an early observation with one of my first Simula programs coded
on a mainframe that told me: "Internal error! Please contact the NCC
in Oslo." - BTW; a nice suggestion, but useless since back these days
there was no Email available to me and the NCC was in another country.