Re: "A diagram of C23 basic types"

On Thu, 3 Apr 2025 15:58:05 +0200
David Brown <david.brown@hesbynett.no> wibbled:

Human readers prefer clear code to comments.  Comments get out of sync -
code does not.

Thats not a reason for not using comments. Its very easy to understand your
own code that you've just written - not so much for someone else or for you
years down the line.

Ignorance is curable - wilful ignorance is much more stubborn.  But I
will try.

Guffaw! You should do standup.

Let me give you an example, paraphrased from the C23 standards:
>
>
#include <stddef.h>
>
enum Colours { red, green, blue };
>
unsigned int colour_to_hex(enum Colours c) {
    switch (c) {
        case red : return 0xff'00'00;
        case green : return 0x00'ff'00;
        case blue : return 0x00'00'ff;
    }
    unreachable();
}
>
>
With "unreachable()", "gcc -std=c23 -O2 -Wall" gives :
>
colour_to_hex:
        mov     edi, edi
        mov     eax, DWORD PTR CSWTCH.1[0+rdi*4]
        ret
>
Without it, it gives :
>
colour_to_hex:
        cmp     edi, 2
        ja      .L1
        mov     edi, edi
        mov     eax, DWORD PTR CSWTCH.1[0+rdi*4]
.L1:
        ret

Except its not unreachable is it? There's nothing in C to prevent you
calling that function with a value other than defined in the enum so what
happens if there's a bug and it hits unreachable? Oh thats right , its
"undefined" ie , a crash or hidden bug with bugger all info.

Neither "// This should never be reached" nor "assert(false);" is a
suitable alternative.

In your opinion. I would never use that example above, its just asking for
trouble down the line.

Also FWIW, putting seperators in the hex values makes it less readable to me
not more.