Re: do { quit; } else { }

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.

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.

 I tend to "cheat" with
these, using "%lu" for uint32_t on the targets I usually use, where I
know uint32_t is "long unsigned int".  Other than that, I stick to
the size-specific types for much of my code except local "throw-away"
variables that might be "int".  Compatibility or lack thereof between
the size-specific types and the standard integer types is simply
irrelevant in my code.