Paul Eggert eggert@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)?

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