Simon Josefsson simon@josefsson.org writes:
Yes. Understanding what the differences is, and which one is right, seems useful first though. If the problem is in gnulib, we can fix that and GnuTLS will have the new variant soon.
Quoting my investigation from an old (off-list) email thread, from November last year:
And the problem seems to be that inttypes.h doesn't define int_fast8_t types. And then AX_CREATE_STDINT_H (used by nettle) and gnulib (used by gnutls) both decide to define them, and they do that in an incompatible way.
---
From a quick look at gl/stdint.h.in and on posted error messages, I think glib uses long for all of int_fast8_t, int_fast16_t and int_fast32_t, and int64_t for int_fast64_t, while nettle uses int8_t, int, int32_t and int64_t.
---
Actually, one ought to have a look at the definitions in the stdint.h provided by gcc (and at the definitions in the solaris10 stdint.h), and make sure the definitions of the int_fast* types are equivalent. Otherwise one might end up with subtle ABI differences and errors when linking together code compiled by different compilers.
Agreed.
I did a quick check. The following seems to be the correct sizes:
int_fast8_t: 1 int_fast16_t: 4 int_fast32_t: 4 int_fast64_t: 8
This is using sizeof on the types defined in stdint.h, trying:
gcc -m32 on solaris 9 gcc -m64 on solaris 9 cc -m32 on solaris 10 cc -m64 on solaris 10
Remarkably enough, they all agree. I also get the same sizes from nettle-stdint.h, for both 32 bit and 64 bit configurations. So I think nettle (or really, AX_CREATE_STDINT_H) gets this right.
While if I understand gl correctly, it uses 4,4,4,8 for a 32-bit build and 8,8,8,8 for a 64-bit build (the size of long is different). This seems wrong. Sure, these are perfectly ok sizes according to C99, but they differ from the sparc conventions (and possibly conventions for other architectures as well).
Regards, /Niels