missing methods in inttypes.h

Corinna Vinschen vinschen@redhat.com
Fri Aug 2 17:41:00 GMT 2013

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.  This is independent of the platform.  The result
of the following testcase is the same on Linux as well as on Cygwin:

  $ cat > x.c <<EOF 
  #include <stdio.h>
  #include <inttypes.h>

  int main(int argc, char **argv)
    printf ("sizeof (__int128) = %zu\n", sizeof (__int128));
    printf ("sizeof (long long) = %zu\n", sizeof (long long));
    printf ("sizeof (intmax_t) = %zu\n", sizeof (intmax_t));
  $ make x
  cc    -c -o x.o x.c
  cc   x.o   -o x
  $ ./x
  sizeof (__int128) = 16
  sizeof (long long) = 8
  sizeof (intmax_t) = 8

That behaviour seems to be not standards conformant...


Corinna Vinschen
Cygwin Maintainer
Red Hat

More information about the Newlib mailing list