Re: "A diagram of C23 basic types"

On 04/04/2025 11:40, Muttley@DastardlyHQ.org wrote:

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.

It is a reason for never using a comment when you can express the same thing in code.

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.

If that's your problem, write better code - not more comments.
Comments should say /why/ you are doing something, not /what/ you are doing.

 

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?

It /is/ unreachable.  That's why I wrote 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?

There's nothing in the English language preventing me from calling you a "very stable genius" - but I can assure you that it is not going to happen.

Oh thats right , its
"undefined" ie , a crash or hidden bug with bugger all info.

Welcome to the world of software development.  If I specify a function as working for input values "red", "green", and "blue", and you choose to misuse it, that is /your/ fault, not mine.  I write the code to work with valid inputs and give no promises about what will happen with any other input.

 

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.
 

Again, that's /your/ problem.