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

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> could you explain how the gnulib created stdint.h would work?

I see two ways it could be done.

First, "configure" could query the standard stdint.h and put the
results of its queries into the Autoconf-generated stdint.h.  There
are some shortcuts here.  If #include_next works, "configure" can use
that; otherwise if "cc -E" works, "configure" can prepend its output
to the "configure"-generated stdint.h.  This will handle the vast
majority of practical compilation environments.

Second, "configure" could put its stdint.h additions into config.h as
macros.  See m4/eoverflow.m4 for an example of how this is done for
errno.h.  This approach is simpler and I think more reliable, if it
solves the problem.

The basic idea is that the source code should just say "#include
<stdint.h>" and should assume the C99 properties for <stdint.h>.

> It is not like the stdbool.h situation: many systems do have a
> stdint.h which contain useful definitions, but it does not contain
> C99/POSIX uint32_t etc.

Just out of curiosity, what systems are these?

I should mention that C99 does not require <stdint.h> to define
<uint32_t>, so portable code cannot assume that uint32_t works.
Instead, portable code must use uint_least32_t or it must
conditionalize the use of uint32_t on UINT32_MAX.