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

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> 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.

I lean toward the latter approach as well.  I'll see if I can find
time to experiment with it, although fixing gnulib-tool --import is
more important for me.

However, this wouldn't solve the problem with using uint32_t in
installed header files.  I guess gnulib could put the new definitions
in foo-int.h, which config.h could #include, and the application could
install foo-int.h.  There are some problems here, though.  First, the
name of the file must not collide.  @address@hidden  Ideally, the
file name should be user defined, but I'm not sure how to do that,
given the current gnulib M4 infrastructure.  Secondly, whether or not,
and where, the header file should be installed is also not clear where
it should be decided.

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

Right.  I'm not convinced I want to assume C99 in some projects yet,
though.  I can settle with assuming C89, with some additions, like
uint32_t.

>> 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 don't recall, and testdrive.compaq.com seem down so I can't check my
first guess (HP-UX).

> 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.

POSIX require uint32_t though, and most sane systems have it, which is
enough for me for now.  Using uint_least32_t to store Unicode code
points seem to invite troubles when interfacing with other
implementations, though.  I doubt many Unicode packages use
uint_least32_t consistently.  Perhaps I should use wchar, but it seem
less portable (wchar not required to hold full Unicode), and nobody
has asked for it, and most importantly, I don't understand it.

Thanks.