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

[Niels Möller]

Paul Eggert <eggert at 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

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