Path: ...!news.tomockey.net!news.samoylyk.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Fri, 4 Apr 2025 13:39:06 +0200
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <vsogcq$3b14s$2@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjjd1$23ukt$1@dont-email.me>
 <vsjkvb$25mtg$1@dont-email.me> <vpdHP.1828825$TBhc.94105@fx16.iad>
 <vslhrm$7uv3$1@dont-email.me> <vsll4b$8mfb$3@dont-email.me>
 <vslq6b$ginf$1@dont-email.me> <vsm45d$ncfh$4@dont-email.me>
 <vso9fa$34vau$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 04 Apr 2025 13:39:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c769e35c057c19c3049ecfc31d4accc3";
	logging-data="3507356"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+3aXLfg3TFmliTs7/TaUCU5Pc/iH3f42g="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:m9T4B/lvqQlukQIgIyZ6d+nULpI=
Content-Language: en-GB
In-Reply-To: <vso9fa$34vau$1@dont-email.me>
Bytes: 4276

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.