missing methods in inttypes.h

[Eric Blake]

On 08/02/2013 11:41 AM, Corinna Vinschen wrote:
> On Aug  2 10:58, Eric Blake wrote:
>> On 08/02/2013 08:27 AM, Craig Howland wrote:
>>>
>>> On 08/02/2013 03:51 AM, Corinna Vinschen wrote:
>>>> That, and the alias implementation would fix all your concerns, as
>>>> long as the types (long long vs. intmax_t) have the same size. Do we
>>>> have targets without long long? Do we have targets with intmax_t >
>>>> long long? I hope not... Corinna 
>>> We do not have any targets with intmax_t > long long, as the standards
>>> require intmax_t >= long long.
>>
>> That's a non sequitur.  It is feasible (although currently unlikely) to
>> have a platform with 64-bit 'long long' but 128-bit 'int128_t'; on such
>> a platform, intmax_t would have to be int128_t.
> 
> That reminds me of a type weirdness.  On x86_64, gcc supports the
> datatype __int128.  Nevertheless, when asking for the size of intmax_t,
> it returns 8, not 16.

That's because intmax_t is still set to the largest non-internal type,
int64_t.  If someone adds 'typedef __int128 int128_t' to expose a
128-bit integer out of the realm of reserved for the implementation and
into the realm of usable by standards-conforming programs, then that
same person better also adjust intmax_t to match.

> 
> That behaviour seems to be not standards conformant...

You left standards conformance behind when you used a double-underscore
keyword.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20130802/eb76f6a4/attachment.sig>