Re: do { quit; } else { }

On 13/04/2025 21:14, Michael S wrote:

On Sun, 13 Apr 2025 20:53:03 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

On 13/04/2025 19:57, Michael S wrote:

On Fri, 11 Apr 2025 11:15:44 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
  

bart <bc@freeuk.com> writes:
[...]

8 A u64 type can be denoted as either 'uint64_t' OR as some
combination of the tokens (long, long, unsigned, [int])

>
"uint64_t" and "unsigned long long int" do not mean the same thing.
 

>
And it's a PITA.
  

>
There is only one thing I find a little bit annoying about the sized
integer types in C - the printf specifiers.

  Yes, in practice it is the main reason why I find absence of
system-independent correspondence between [u]intn_t types and basic
integer types a PITA. But there exist few other cases where it causes
problems, e.g. using Intel intrinsic like _addcarry_u64() in code that
have to be compiled on different 64-bit OSes.

I don't find that a PITA, because I don't have to write such code :-)
(I appreciate that other people might have things they don't like about the sized integer types, or have code for which potential incompatibilities between types with the same size and representation can be annoying.  I can only complain about the things I find annoying.)

 As to why you feel stronger than you about it, I'd guess it's because I
write code that has to be compiled, preferably without warnings, on
different platforms more often than you do. Most of 32-bit and 64-bit
platforms are compatible to each other, but 64-bit Unix/Linus is at
odds with the rest of them.
 

My targets for C (and C++) are mostly 32-bit ARM these days, and the smaller microcontrollers I sometimes use are consistent with ARM in having "uint32_t" be "unsigned long int".  I occasionally also target 64-bit Linux, but I haven't had any issues there either - but that may be due to the type of code I have written.