Simon Josefsson wrote:
> >> The essential difference is that the installed "idn-int.h" should work
> >> without assuming any config.h symbols, but instead rely on a
> >> combination of install-time "guesses" and CPP symbol checks to define
> >> the proper uint32_t types for the host and the compilers on that host.
> >
> > Sorry, I cannot see how a CPP symbol test can tell whether uint32_t is
> > defined, if I don't know the compiler a priori. And #ifdefs of known
> > systems is not the right approach - not autoconfiguring, hard to maintain.
>
> I was thinking of the 32-bit vs 64-bit problem, there is often some
> CPP symbol that indicate if the compiler is in 32-bit mode or 64-bit
> mode.
I have now changed the generated stdint.h so that it is independent of
config.h symbols (same trick as for stdbool.h).
But multi-arch support ("fat" include files that work in 32-bit mode and
64-bit mode, or binaries that work on different platforms of the same OS)
are outside the scope of autoconf and gnulib. You can glue together two
generated stdint.h files yourself.
> Use of int_fastN_t in public APIs is probably a bad idea anyway,
> since it isn't ABI-safe.
I added a comment about it in the file.
> >> (called something like "idn-int.h")
> >
> > Why not call it "stdint.h"?
>
> I'd think that would be too error-prone, all packages using the same
> scheme would then have colliding filenames.
But on the other hand, if you define types like uint32_t in "idn-int.h",
then another copy of gnulib's stdint.h will miss it, leading to collisions.
Bruno
