[Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions)

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> This doesn't work with installed header files, does it?
>
> Ad 1) How to install header files which define uint32_t?
>
> I recommend to just not do it. The reason is that only one typedef for
> uint32_t is possible in a compilation unit. On a platform that does not
> define uint32_t by itself, it's likely that many packages will define it.
> Some will define it differently. What happens then? You can avoid the
> compilation errors by using #define instead of typedef, but this still
> doesn't resolve the problem.
>
> In the similar case with errno values (good comparison, Paul!) I once had
> the case, on a platform lacking EILSEQ (BSD/OS I think), one piece of
> software did      #define EILSEQ  EINVAL
> and another did   #define EILSEQ  ENOENT.
> The program crashed, of course, because it didn't interpret the errno
> values correctly. Similar things will happen if one piece of code
> defines intmax_t as being a 32-bit type, and for another compilation unit
> it's a 64-bit type.
>
> The workaround, ugly as it is, is to define library specific types,
> such as idn_uint32_t. GNU gettext has been using
>   typedef unsigned int nls_uint32_t;
> for years without problems.

I understand your argument, but the workaround has so pervasive
consequences that I want to try to find a better compromise.

Having to replace all occurrences of uint32_t with @address@hidden
in every package not only produce hard to read source code, but also
interesting type casting problems: is it OK to cast idn_uint32_t to
nls_uint32_t?  To see where it may be confusing, compare gss_uint32_t
(see source code comment in other post) which is not really equivalent
to the real uint32_t.  Yes, the confusing definition of gss_uint32_t
is evil, but the API is from an RFC and isn't likely to change due to
interoperability concerns.  This might not be a strong argument, but
it is enough for me to doubt that workaround.

> I would propose to let the autoconf macro determine the full pathname of
> the system's <stdint.h> (through "$CC -E" and grepping for #line statements),
> and do a #include of this full pathname at the beginning of our stdint.h.

What if the system has several compilers, each with its own stdint.h?

I realize the M4 macro I posted probably doesn't handle this either,
but if we are thinking about a proper solution, let's do that.

Thanks.