Re: "A diagram of C23 basic types"

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

On 03/04/2025 10:45, Muttley@DastardlyHQ.org wrote:

On Wed, 02 Apr 2025 16:16:27 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled: 

Muttley@DastardlyHQ.org writes: 

On Wed, 2 Apr 2025 16:59:45 +0200
David Brown <david.brown@hesbynett.no> wibbled: 

On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote: 

ist first. 

 

18. "unreachable()" is now standard. 

>
Googled it - don't see the point. 

>
That's a defect in your understanding, not a defect in the
standard.
>
I've found  the gcc equivelent useful often in standalone
applications (OS, Hypervisor, standalone utilities, etc). 

 
Enlighten me then.
 

 
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:
 
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
 
Mostly I have it wrapped in macros that let me conveniently have
run-time checking during testing or debugging, and extra efficiency
in the code when I am confident it is bug-free.
 
Good use of __builtin_unreachable() can result in smaller and faster
code, and possibly improved static error checking.  It is related to
the C++23 "assume" attribute (which is also available as a gcc
extension in any C and C++ version).
 
 

In theory, compilers can use unreachable() to generated better code.
In practice, every single time I looked at compiler output, it made no
difference.