Re: do { quit; } else { }

On 14.04.2025 03:03, James Kuyper wrote:

On 4/13/25 15:14, Michael S wrote:
...

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.

 
Well the basic integer types were intended to be system-specific,
specifically to allow each implementation to choose whatever worked best
for the target platform. That's one of the features that helped ensure
that there's a fully conforming implementation of C for such a wide
variety of platforms. The size-named types came later, and it is of
course impossible for the correspondence between system-specific and
size-named types to be system-independent.

Honestly, this is an old, known argument that I could never fully
understand. 'char' for characters, 'int' as a register sized entity,
'short' and 'long' as, say, additions. So far so good. "For a wide
variety of platforms" you cannot just use 'int' and hope that works
on 8, 16, or 32 bit processors the same way. Switching to 'long' or
'short' also doesn't provide any portability property since you've
no guarantee whether the necessary ranges can be represented with
them. That's why we had introduced types with size-guarantee (that
later became part of the language for obvious reasons). Consequently
we have always provided explicit (e.g. CPP controlled) conditional
compiles of these types. And then there was the coinciding printf()
format specifier issue; so there's again means necessary to address
that (say, own low-level functions for explicitly determined types).
In short; in practice these types did not help us WRT portability,
or only in the more conservative application cases.

Janis