This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: missing methods in inttypes.h

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

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]