Bruno Haible <[EMAIL PROTECTED]> writes:
> Here is a proposed rewrite of the stdint module. It defines a
> *complete* <stdint.h>, and is autoconfiguring - no more
> #ifdef __FreeBSD__ etc. that are hard to maintain.
>
> It appears to work fine on Solaris and HP-UX IA64.
>
> The only downside is that it bloats up 'configure' - but autoconf 3
> should annihilate that growth, I'm told.
Autoconf 3 won't be out for quite some time, I'm afraid.
The approach assumes a conventional architecture in which there are
underyling signed and unsigned types of width 8, 16, 32, and 64, and
the only argument is which int*_t type is which. That's likely the
only case worth worrying about, for backward compatibility reasons
anyway. How about simplifying things as follows?
1. If the system <stdint.h> doesn't work, we omit it entirely,
and substitute our own entirely.
2. We work around incompatibilities between our substitute
and the standard header files by having our stdint.h substitute
do this first:
#define int_fast32_t rpl_int_fast32_t
#define int_fast64_t rpl_int_fast64_t
...
[include <sys/inttypes.h>, FULL_PATH_INTTYPES_H, etc., here]
#undef int_fast32_t
#undef int_fast64_t
...
#undef INT_FAST32_MIN
#undef INT_FAST32_MAX
#undef INT_FAST64_MIN
#undef INT_FAST64_MAX
An advantage of this approach is that we will work around subtle bugs
in existing implementations, if ours is good. For example, on Solaris
10, UINT16_MAX is (65535U) which is incorrect; it's supposed to be a
signed value. (Both the current and the proposed stdint.h have the
same bug, but we can fix it. :-)
Another advantage is that it won't require many Autoconf tests;
basically, whether 'long' is 32 or 64 bits, and whether 'long long' is
available (we can assume it's 64 bits, I suppose).
A disadvantage of this approach is that if our opinion of int_fast32_t
disagrees with that of the (broken) system file, and if some other
system header uses int_fast32_t, then we could be hosed.
