bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on S


From: Niels Möller
Subject: Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Date: Sun, 06 May 2012 09:13:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (usg-unix-v)

Paul Eggert <address@hidden> writes:

> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.

Why (feel free to point to the relevant section of gnulib docs, if it's
explained well there)?

Maybe nobody uses these types so it's an academic issue, but if these
types are used in the interface to any library (possibly some system
library), then it's important that applications agree on the definition.
To me, it seems like the authoritative definition of int_fast*_t ought
to be the system's ABI specification.

And in the case of SunOS-5.9, where the types are missing, I think it
makes the most sense to adopt the ABI of SunOS-5.10. Which also seems to
be what gcc does.

I'm a bit confused by your statement. I had the impression that gnulib
*does* fall back on the definitions in public headers like <stdint.h>
and <inttypes.h>, for the types which *are* defined there. And that's
why nettle and gnutls seem to work together on SunOS-10. Correct?

> This is a documented issue in Gnulib.
> It's hard to imagine a general fix for this.

One possibility might be to not define the types at all, unless the
gnulib application *explicitly* asks for them. Lots of applications want
uint32_t, and I imagine a lot fewer have any need for int_fast*_t.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]