missing methods in inttypes.h

[Corinna Vinschen]

On Aug  2 11:58, Eric Blake wrote:
> 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.

Ooh, the fine points... ;)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat