Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Sort char array
Date: Wed, 16 Oct 2019 16:33:29 -0700
Organization: None to speak of
Lines: 38
Message-ID: <ln36fsfepi.fsf@kst-u.example.com>
References: <STKlF.8551$oU2.5908@fx21.iad> <rvKmF.2513170$dw4.1447457@fx12.am4> <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> <1q_mF.841756$Zy3.585129@fx33.am4> <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> <qnkd2j$hpb$1@dont-email.me> <5alnF.1041354$WI2.353384@fx34.am4> <qnknn7$hs7$1@dont-email.me> <dd99aeb0-e773-4bf8-8244-3b2564f992c1@googlegroups.com> <qnl92t$ns$1@dont-email.me> <5b525fc7-aeb6-47ec-b425-526a60d31e92@googlegroups.com> <qnohio$tou$1@dont-email.me> <f813b10d-187b-4393-adf2-e75779ff31b0@googlegroups.com> <qnq6k4$dse$1@dont-email.me> <ln5zkvtaet.fsf@kst-u.example.com> <qns9uj$umt$1@dont-email.me> <lno8ylsrh5.fsf@kst-u.example.com> <qo4rse$o8a$1@dont-email.me> <86bluh54he.fsf@linuxsc.com> <lneezcfkub.fsf@kst-u.example.com> <qo884n$3as$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="23aeadce0f0c83a8e511abf23a19647d"; logging-data="20716"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19PW/zT7QxLmG3rNGXcQwIx"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:40Y7A+oOSLtgmrvGIhub13Wn4/g= sha1:BQF1LiV15Wtkv3cSQyeznkK9lnI=
Xref: csiph.com comp.lang.c:147013

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/16/19 5:21 PM, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>>> though the standard fails to mandate it.  If so, and you #include
>>>> <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is
>>>> required to expand to an integer constant expression with the same type
>>>> as the promoted type of int_least128_t (7.20.4.1).
> ...
>>>
>>> I believe it could be done completely portably as follows:
>>>
>>>     #define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n)
>> 
>> 7.20.4p1 requires INTn_C(value) to expand to an integer constant, not
>> just an integer constant expression.  I'm not sure that requirement is
>> necessary (i.e., I'm not sure we'd lose anything if it were allowed more
>> generally to be an integer constant expression), but there it is.
>
> "The macro INTN_C(value) shall expand to an integer constant expression
> corresponding to the type int_leastN_t." (7.20.4p1).

That's 7.20.4.1p1.  7.20.4p1 says:
    The following function-like macros expand to integer constants
    suitable for initializing objects that have integer types
    corresponding to types defined in <stdint.h>.

Of course an integer constant is an integer constant expression,
but I don't know why the paragraph you quoted uses the more general
term when the paragraph above it uses the more specific term.
It's hard to tell what the intent is.  I think this is a flaw in the
standard.  (The same flaw appears in the latest draft, N2386.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */