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 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: References: <87y0wjaysg.fsf@gmail.com> 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: Bytes: 4276 On 04/04/2025 11:40, Muttley@DastardlyHQ.org wrote: > On Thu, 3 Apr 2025 15:58:05 +0200 > David Brown 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 >> >> 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.