Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc

[Paul Eggert]

On 05/06/2012 12:13 AM, Niels Möller wrote:
> Paul Eggert<eggert at cs.ucla.edu>  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)?

Intuitively, it's because the int_fast* types are so fragile: they
depend so much on choice of compiler and compiler option.  (To some
extent the types are even a mistake, as modern compilers optimize
so well without them.)  That is why gnulib never uses these types
in public headers (except for stdint.h where C requires it).

Gnulib lib/stdint.in.h says this:

/* Note: Other <stdint.h> substitutes may define these types differently.
    It is not recommended to use these types in public header files. */

and it seems like it may be worthwhile to add this to the documentation,
so I pushed this:

stdint: document issues with int_fast8_t etc.
* doc/posix-headers/stdint.texi (stdint.h): Say that other
stdint.h substitutes may define these types differently.  See
<http://lists.gnu.org/archive/html/bug-gnulib/2012-05/msg00071.html>.
diff --git a/doc/posix-headers/stdint.texi b/doc/posix-headers/stdint.texi
index be19269..aeae7d5 100644
--- a/doc/posix-headers/stdint.texi
+++ b/doc/posix-headers/stdint.texi
@@ -40,6 +40,8 @@ Portability problems not fixed by Gnulib:
  @item
  @code{@{uint,int@}_fast@{8,16,32,64@}_t} may not correspond to the fastest
  types available on the system.
+Other @code{<stdint.h>} substitutes may define these types differently,
+so public header files should avoid these types.
  @item
  Macros are used instead of typedefs.
  @item