Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Mon, 14 Apr 2025 06:43:11 +0200
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <vti3p0$h094$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <86ecy5fjin.fsf@linuxsc.com>
 <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com>
 <20250407210248.00006457@yahoo.com> <vt15lq$bjs0$3@dont-email.me>
 <vt2lp6$1qtjd$1@dont-email.me> <vt31m5$2513i$1@dont-email.me>
 <vt3d4g$2djqe$1@dont-email.me> <vt3iqh$2ka99$1@dont-email.me>
 <vt5fed$ccri$1@dont-email.me> <vt5js2$g1t7$1@dont-email.me>
 <20250409142303.00004645@yahoo.com> <87ikndqabc.fsf@nosuchdomain.example.com>
 <20250410115501.000037a5@yahoo.com> <vt8ei8$2vn84$1@dont-email.me>
 <20250410080629.532@kylheku.com> <vt94q5$3jjod$1@dont-email.me>
 <vt9628$3hhr8$3@dont-email.me> <vtammh$174ev$1@dont-email.me>
 <vtavn9$1dp7m$3@dont-email.me> <87r01ysgxb.fsf@nosuchdomain.example.com>
 <20250413205703.000059ce@yahoo.com> <vth16f$3g7ar$1@dont-email.me>
 <20250413221457.000029b3@yahoo.com> <vthmst$26ud$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 14 Apr 2025 06:43:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a33294dcd0843173374a50cf90c49dd0";
	logging-data="557348"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tRx0cRmDEw1Fi/vCcfcyc"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:onJ4NMzTCAzsfJHaFRMu84Y06Lk=
In-Reply-To: <vthmst$26ud$3@dont-email.me>
X-Enigmail-Draft-Status: N1110
Bytes: 3822

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