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 14:21:00 -0700
Organization: None to speak of
Lines: 35
Message-ID: <lneezcfkub.fsf@kst-u.example.com>
References: <STKlF.8551$oU2.5908@fx21.iad> <XyHmF.665592$qd4.648019@fx17.am4> <20191007174244.385138503569a8bc6d4eec9d@g{oogle}mail.com> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="d40171aac15a316bcd179f9b63c5f106"; logging-data="30687"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pIJtLcNsnV9SU4QGVxgZe"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:M2SdH+TjydU8ZdbryFAN7iFZWSo= sha1:VBDbaIC38jOFauQVKBM09ogKOUM=
Xref: csiph.com comp.lang.c:147011

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/12/19 3:17 PM, Keith Thompson wrote:
>> ...
>>
>>> I don't see a requirement in the standard to support constants of
>>> type int128_t.  But an implementation could support such constants
>>> as an extension.  (gcc doesn't.)
>>
>> That's true, but if int128_t is supported, it's inherently the case that
>> int_least128_t can be supported too, and I think that it should be,
>> 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).  That would be same as
>> int_least128_t except in the extremely unlikely case that
>> INT_LEAST128_MAX < INTMAX :-).  On most systems that support int128_t,
>> I'd expect int_least128_t to be the same as int128_t.
>> Therefore, the expansion of INT128_C() is likely to involve some
>> non-portable method that could be used to create such constants without
>> using that macro.
>
> 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.

-- 
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 */