Re: "A diagram of C23 basic types"

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

On Fri, 4 Apr 2025 13:39:06 +0200
David Brown <david.brown@hesbynett.no> wibbled:

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.
>
If that's your problem, write better code - not more comments.

 Ah, the typical arrogant programmer who thinks their code is so well written
that anyone can understand it and comments arn't required. Glad I don't have
to work on anything you've written.

Arrogance would be judging my code without having seen it.  Writing code that is clear and does not require comments to say what it does is not arrogance - it is good coding.

 

>
Comments should say /why/ you are doing something, not /what/ you are doing.

 Rubbish. A lot of the time what is being done is just as obtuse as why.

That can /occasionally/ be the case.  But if it happens a lot of the time, you are writing poor code.  It's time to refactor or rename.

 

Except its not unreachable is it?

>
It /is/ unreachable.  That's why I wrote it.

 Really?
 int main()
{
colour_to_hex(10);
return 0;
}

UB.  It's /your/ fault.
Most of my code is written on the assumption that the people using it are not incompetent morons.  They may make mistakes in their coding, but not like that.  The code in question is unreachable because the kind of person who could write a call like that would not be working with my code.
There are situations where you want to make your code handle as wide a range of inputs as possible, and provide error returns to help catch mistakes.  Typically that is for boundary or interface code - such as libraries written for other people to use.
For internal code within TU's or parts of a project, such things are just a waste of effort.  They can make it significantly harder to design the code, since you have to figure out what behaviour is appropriate for invalid input - what should a function called "colour_to_hex" do when presented with an input that is not a colour?  Sometimes they are impossible to implement - how do you check the precondition "this is a valid pointer" ?  They limit your functionality and future expansion - if I have specified that inputs other than "red", "green" or "blue" give the result 0x00'00'00, then I can't add "purple" to the list of colours.
There are all sorts of reasons why it is a good idea for functions to have pre-conditions, and for letting calls to the function without satisfying those pre-conditions be undefined behaviour.

 You have no idea how someone might try and use that function in the future.

Yes, I do.

Just assuming they'll always pass parameters within limits is not just
cretinous, its dangerous.

Nope.  It is how software development works.  If you don't understand about function specifications, you might want to read up on some basic computer science.

 

  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.

 Poor analogy.
 

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.

 Its your fault if it dies in a heap with no info or worse returns but does
some random shit.

If the caller fails to satisfy the pre-conditions of the function, that's the caller's fault.  If the function fails to satisfy the post-conditions when called with correct pre-conditions, that's the function's fault.  That's the contract, and that's the basis of all programming.

Any well written API function should do at least basic
sanity checking on its inputs and return a fail or assert unless its very low
level and speed is the priority eg strlen().
 

At clear boundaries of development responsibility - such as the public functions of a library - then it is often nice to add some extra checking and error feedback to help users of the library find their bugs.

But then you're arrogant, so no surprise really.
 

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

>
Again, that's /your/ problem.

 See above.