Hi Niels, (adding bug-gnulib@)
Am 27.04.2012 um 17:24 schrieb Niels Möller: > Simon Josefsson <si...@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). I see different possibilities on how this can be resolved: 1. nettle uses the gnulib definitions 2. gnulib changes the definitions to conform to nettle Maybe someone from the gnulib list can give some more advice on this? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
