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

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Wouldn't it be nicer to have a module where source code looks like this:
>
> #include <stdint.h>
>
> and everything else is managed behind the scenes?  That is how the
> stdbool module works.  You can look to stdbool to see how it's done.

This doesn't work with installed header files, does it?  I.e.,
/usr/include/idna.h need uint32_t on C89 systems, so #include
<stdint.h> isn't enough, if the header file should work on non-gnulib
applications.

Further, could you explain how the gnulib created stdint.h would work?
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.  I think the generated stdint.h may want to
#include the real /usr/include/stdint.h, but if the generated file has
the same name, I'm not sure how that would work.

However, perhaps there are two separate cases:

1) Installed header files need uint32_t.
  1a) Assume C99: #include <stdint.h>
  1b) Assume C89 together with gnulib environment: #include <stdint.h>
  1c) Assume C89: #include <foo-int.h>, and install foo-int.h

2) Source code need uint32_t.
  2a) Assume C99: #include <stdint.h>
  2b) Assume C89 together with gnulib environment: #include <stdint.h>
  2c) Assume C89: #include <foo-int.h>, no need to install foo-int.h.

I think the macro I posted can support all these cases, since you can
decide what the generated file is called, and whether it is installed
or not is decided by the makefile.

For me, I don't think 1b is a good choice.  Perhaps even 2b is bad.

I agree that for projects that want to assume C99, gnulib should
support the <stdint.h> approach.

Alternatively, gnulib could define an AC_SUBST(INCLUDE_STDINT) and I
can put INCLUDE_STDINT in idna.h.in and have configure generate the
real header file, with the proper #include's or typedef's, as
appropriate.  I'm not sure I like the idea completely, though.

Thanks.