Paul Eggert eggert@cs.ucla.edu writes:

Such usage violates the C standard: even if one compiler is not picky about it, your're likely to run into another that does. So a better solution is needed.

I've committed a workaround to nettle-types.h. It now does

/* Pretend these types always exists. Nettle doesn't use them. */ #define _STDINT_HAVE_INT_FAST32_T 1

#include "nettle-stdint.h"

which overrides the result of the configure checks used in the generated nettle-stdint.h. Maybe not the prettiest way to do it, but apparantly it solves the problem, independently of your fixes to gnulib. (But I'd still like to know if your fixes also solves this problem, independently of that Nettle workaround).

I'd rather have an approach where the code simply does "#include <stdint.h>" and assumes that int_fast8_t works. I don't understand the overall situation, though, so I don't know what exactly to suggest.

I think when you build gnutls on a system lacking stdint.h, a typical compilation unit will contain

/* From gnulib's stdint.h */ typedef unsigned int gl_uint32_t; #define uint32_t gl_uint32_t ...

/* From nettle/nettle-stdint.h */ typedef unsigned int uint32_t;

where the final line is macro-expanded to

typedef unsigned int gl_uint32_t;

From what I've seen, this has been no problem. And I hope

nettle-stdint.h and gnulib/stdint.h always do these types in the same way. There is some freedom in how to define these types; on a system where for example int and long are the same size,

typedef unsigned long uint32_t; typedef unsigned int uint32_t;

would be a two distinct but correct definitions, and I imagine the compiler would complain. And to consider the problematic int_fast*_t types, until a day or two ago, you got

/* From gnulib's stdint.h */ typedef long gl_int_fast8_t; #define int_fast8_t gl_int_fast8_t ...

/* From nettle/nettle-stdint.h */ typedef char int_fast8_t;

which no reasonable compiler will accept.

Regards, /Niels