Re: stdint module rewrite

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Is there anything in this that would enable me to install a "stdint.h"
>> file in $prefix
>
> We could just need to change all
>   #if HAVE_...
> into
>   #if @HAVE_...@
> and use more substitutions in the creation of the stdint.h file.
>
> But there are two problems:
> - It's compiler dependent. On the same platform, a compiler can have
>   uint32_t (or 'long long' etc.) and another can lack it.

I suppose this will have to be one limitation.  Since this is only
applicable to systems that lack stdint.h, having some limitations
seems acceptable to me.

It is possible to handle some cases, though, like running the same
compiler in 32-bit mode and 64-bit mode, and pick the correct types.
I think the AX_... macro does this today.

> - Even with the same compiler, the choice of the int_fastN_t types
>   is arbitrary. Another person might create an <stdint.h> that
>   defines them differently.

Yup.  Use of int_fastN_t in public APIs is probably a bad idea anyway,
since it isn't ABI-safe.

>> (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.  While in theory you could
just use the latest generated stdint.h, I think it creates unnecessary
problems for people packaging the code.

>> Compare the AX_CREATE_STDINT_H macro:
>> http://autoconf-archive.cryp.to/ax_create_stdint_h.html
>> 
>> 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.

/Simon