Re: 128-bit integer - nonsensical documentation?

[David Brown <david at westcontrol dot com>]

On 26/08/15 18:02, Martin Sebor wrote:
> On 08/26/2015 06:13 AM, David Brown wrote:
>> On 26/08/15 13:04, Kostas Savvidis wrote:
>>> The online documentation contains the attached passage as part of the
>>> "C-Extensionsâ chapter. There are no actual machines which have an"
>>> integer mode wide enough to hold 128 bitsâ as the document puts it.
>>> This would be a harmless confusion if it didnât go on to say ââ long
>>> long integer less than 128 bits wideâ (???!!!) Whereas in reality
>>> "long long intâ is 64 bits everywhere i have seen.
>>>
>>> KS
>>>
>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>>   6.8 128-bit integers
>>>
>>> As an extension the integer scalar type __int128 is supported for
>>> targets which have an integer mode wide enough to hold 128 bits.
>>> Simply write __int128 for a signed 128-bit integer, or unsigned
>>> __int128 for an unsigned 128-bit integer. There is no support in GCC
>>> for expressing an integer constant of type __int128 for targets with
>>> long long integer less than 128 bits wide.
>>>
>>
>> You can use __int128 integers on any platform that supports them (which
>> I think is many 64-bit targets), even though "long long int" is
>> typically 64-bit.  The documentation says you can't express an integer
>> /constant/ of type __int128 without 128-bit long long's.  It is perhaps
>> not very clear, but it makes sense.
>>
>> Thus you can write (using C++'s new digit separator for clarity):
>>
>> __int128 a = 0x1111'2222'3333'4444'5555'6666'7777'8888LL;
>>
>> to initialise a 128-bit integer - but /only/ if "long long" supports
>> 128-bit values.  On a platform that has __int128 but 64-bit long long's,
>> there is no way to write the 128-bit literal.  Thus you must use
>> something like this:
>>
>> __int128 a = (((__int128) 0x1111'2222'3333'4444LL) << 32)
>>     | 0x5555'6666'7777'8888LL;
>>
>> This is, I believe, the main reason that __int128 integers are an
>> "extension", but are not an "extended integer type" - and therefore
>> there is no int128_t and uint128_t defined in <stdint.h>.
> 
> It's the other way around. If __int128_t were an extended integer
> type then intmax_t would need to be at least as wide. The width
> of intmax_t is constrained by common ABIs to be that of long long,
> which precludes defining extended integer types with greater
> precision.
> 

Is it fair to say that the main use of extended integers is to "fill the
gaps" if the sequence char, short, int, long, long long has missing
sizes?  Such as if an architecture defines int to be 64-bit and short to
be 32-bit, then you could have an extended integer type for 16-bit?

>>
>> Maybe what we need is a "LLL" suffix for long long long ints :-)
> 
> The standard permits integer constants that aren't representable
> in any of the standard integer types to have an extended integer
> type so a new suffix isn't strictly speaking necessary for
> extended integer type constants.
> 

Is that allowed even if __int128 is not an "extended integer"?  I can
see why gcc would not want to make __int128 an extended integer, if it
then causes knock-on effects such as changing intmax_t.  But if the
standards allow for literals of type __int128 even if it is not defined
as an extended integer, then that might be a nice feature to make the
type more complete and consistent.

Are you allowed to include typedefs for uint128_t and int128_t in
<stdint.h>, or would that also only be allowed if it is a proper
extended integer?

(This is all mere curiosity on my side - I personally have no need of
128-bit integers, and only got involved in the the thread to try and
help the original poster understand what was meant by the documentation.)