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: Don't be fooled by cpp.sh
Date: Fri, 10 Jan 2020 08:29:48 -0800
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <86sgkn46mb.fsf@linuxsc.com>
References: <70391932-ccbc-4bc7-b693-881ab06eb6d3@googlegroups.com> <qt29lv$1jri$1@gioia.aioe.org> <qt35ir$f1o$2@dont-email.me> <d526bf37-7986-4538-8b71-6f3f3e5f5b3d@googlegroups.com> <wbdJF.6510$O9t.3420@fx36.am4> <356f42b0-2919-4e72-a1a2-3813212973f1@googlegroups.com> <7f5255fa-f634-4dc7-9f33-409acc47356c@googlegroups.com> <qt71ni$128$1@dont-email.me> <a5d2c6e9-f755-4a1c-90c1-60b3d5f41649@googlegroups.com> <a6a63628-8c28-4500-a6bb-ac028a854b10@googlegroups.com> <2a6b4b2d-283f-4b5f-9f4c-025efaa087a8@googlegroups.com> <qt7g4h$2l0$1@dont-email.me> <qt7t3h$a2l$1@dont-email.me> <qt8824$coh$1@dont-email.me> <87v9qgvw28.fsf@bsb.me.uk> <qt8r9o$a9i$1@dont-email.me> <878snbwq5h.fsf@bsb.me.uk> <qtan22$t3o$1@dont-email.me> <87r213ui3i.fsf@bsb.me.uk> <qtaq7j$glq$1@dont-email.me> <87o8w6vihg.fsf@nosuchdomain.example.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="7b070c0766e341d0df2bb5814a4c869f"; logging-data="2755"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18bul4fRVXIOFp+ddn6riRlmeg530K642c="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:uFz85eaDwhwsl9BSdxrjUPqqf8g= sha1:/Dx0A586G1zVTDiZ4Lx515IAGlo=
Xref: csiph.com comp.lang.c++:71262

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@hesbynett.no> writes:
> [...]
>
>> __int128 meets almost all the technical requirements to be a signed
>> integer type - the only missing one is the classification, as that would
>> mean maxint_t would have to be (at least) 128 bits.
>
> It doesn't meet *all* the requirements.  N1570 6.4.4.1p6 (Integer
> constants):
>
>     If an integer constant cannot be represented by any type in its
>     list, it may have an extended integer type, if the extended integer
>     type can represent its value.
>
> In gcc, there are no constants of type __int128.
>
> (The word "may" is a bit ambiguous, and it could be argued that an
> implementation isn't required to support constants of type int128_t
> even if it's an extended integer type.)

Not really convincingly.  The end of that paragrah says

    If an integer constant cannot be represented by any type in
    its list and has no extended integer type, then the integer
    constant has no type.

I don't see any sensible way of reading those sentences together
and concluding that using an extended integer type is allowed to
be optional.