Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Sort char array
Date: Wed, 16 Oct 2019 04:12:13 -0700
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <86bluh54he.fsf@linuxsc.com>
References: <STKlF.8551$oU2.5908@fx21.iad> <qnf974$aiu$1@dont-email.me> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="60f5432ae2a60ffae1456cdecfea50b0"; logging-data="29346"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XX/pPv9OioEwlDKsjcLRURerlXIPQ4U0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:79/XVBKEKoePl6iGEFAELUZUByo= sha1:9KA+6DrcQlQ5z9IQ7acbkajYO/c=
Xref: csiph.com comp.lang.c:147007

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)