Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Richard Heathfield <rjh@cpax.org.uk>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Tue, 15 Apr 2025 09:18:15 +0100
Organization: Fix this later
Lines: 52
Message-ID: <vtl4o7$39391$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>
 <vti3p0$h094$1@dont-email.me> <vtj0sr$19625$1@dont-email.me>
 <vtl2h3$37onb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 15 Apr 2025 10:18:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="518c54d255421e14a04c2a4e021ec872";
	logging-data="3444001"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180v7NtKA6NTZjPJARMJruSVDXM5AB6Tqgfx2hJiwD/wA=="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:aNtxVRy8N5FQtMFjlYPs0HdrZug=
In-Reply-To: <vtl2h3$37onb$1@dont-email.me>
Content-Language: en-GB
Bytes: 3658

On 15/04/2025 08:40, Janis Papanagnou wrote:
> On 14.04.2025 15:00, James Kuyper wrote:
>> On 4/14/25 00:43, Janis Papanagnou wrote:
>> ...
>>> 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.
>>
>> Huh? There's guarantees for every one of those types.
> 
> Has that changed?

No. The guarantees go at least as far back as 1989.

> - I recall that there were only "compare to"
> relations defined, like               |short| <= |int| <= |long|

 From back in the day:

[quote from ANSI C89]

2.2.4.2 Numerical limits

    A conforming implementation shall document all the limits 
specified in this section, which shall be specified in the 
headers <limits.h> and <float.h> .

"Sizes of integral types <limits.h>"

    The values given below shall be replaced by constant 
expressions suitable for use in #if preprocessing directives. 
Their implementation-defined values shall be equal or greater in 
magnitude (absolute value) to those shown, with the same sign.

[end quote]

The Standard then dictates the minimum ranges that each numerical 
type must support.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within