Paul Eggert eggert@cs.ucla.edu writes:

Intuitively, it's because the int_fast* types are so fragile: they depend so much on choice of compiler and compiler option.

Short version: I think gnulib should either make an effort to define int_fast*_t in the common way on each system (always doing the same as gcc would be very close to the Right Thing), or by default generate a stdint.h without these types and define the int_fast*_t types only when explicitly asked to.

Longer version (sorry I fail to be more concise):

I think I misread "public headers" in your previous mail, I thought you meant system header files, rather than public header files provided by portable non-system libraries. Sorry for the confusion. I agree one can expect these types to be a fragile and compiler dependent whenever they're left undefined by system headers and ABI spec, which will be the usual assumption for portable code.

But in the particular case of SunOS, the types are defined by system headers in release 5.10 (and presumably nailed down by the ABI spec), but missing in release 5.9. Do you see any good reason for gnulib to not define the types in the same way as on 5.10, if building on 5.9?

To me, that really looks like the Right Thing to do, and it also looks like the kind of job gnulib is supposed to do. Defining them in a way which differs from SunOS-5.10 definitely seems broken. In the case of gnutls and nettle, one gets compilation errors when another packed defines the same types, and does it using a configure hack which *is* compatible with SunOS-5.10. Of course, that fix doesn't magically make int_fast*_t universally non-fragile, but it definitely improves compatibility for the system in question.

As for nettle, I think it's best to not define these types, which aren't used. On Solaris, it happens that AX_CREATE_STDINT_H defines them more correctly (in my view) than gnulib, but it may well cause problems on other system, so it seems more robust to not try to define them at all.

But please also consider the hypothetical situation that nettle *did* use those types, even if only internally. Then I couldn't simply omit the definitions. To not cause problems for gnulib users I'd be forced to either change my definitions to prefer compatibility with gnulib over compatibility with SunOS-5.10, which seems really backwards, or introduce additional complexity in nettle-stdint.h to omit the definitions when my public headers need uint32_t.

Regards, /Niels