This is the mail archive of the newlib@sourceware.org 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] |
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
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] |