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

[Bruno Haible]

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.


Ad 2) What can we do for source code that needs uint32_t?

Pre-remark: There are platforms which don't have 32-bit types. From my
reading of the X11 source code, it appears that CRAY (or some versions
of it) are in this category. Do you want a uint32_t in the <stdint.h>
emulation in all cases, or not?

What I like about your AX_CREATE_STDINT_H macro is that it performs
many autoconf tests, as necessary. What I don't like about it, is that
this shell script code is hard to understand. The

   #if HAVE_FOOBAR

style in all gnulib *_.h files, or the

   #if @HAVE_FOOBAR@

style in stdbool_.h, lead to more readable source code, in my opinion.

Now, the big problem here is that we want to _extend_ the platform's
<stdint.h> with a file that is also called stdint.h. There are a few
caveats:

  - Our stdint.h must invoke the system's <stdint.h> when it exists.
    If not, the user could include the system's <stdint.h> (accidentally:
    other system headers sometimes play tricks that cause the system's
    header file to be taken even if there's another one in the search
    path - I've seen such things with <libintl.h> and <locale.h> on
    Solaris) and get type clash errors.

  - Paul Eggert writes:
    > If #include_next works, "configure" can use
    > that; otherwise if "cc -E" works, "configure" can prepend its output
    > to the "configure"-generated stdint.h.
    #include_next is not portable, and "cc -E" cannot reproduce the
    preprocessor defines that are contained in a header files. (Only
    "gcc -E -dM" can, but we cannot assume gcc.)

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.

The #includes of <sys/inttypes.h> etc. are easier: they can be normal
#if-protected includes.

Then comes a ton of #ifdef, according to criteria like the LP32/LP64/...
distinctions from Simon's macro.

Bruno