Paul Eggert wrote:
> 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.
Yes, and it does so using the approach "use what the system provides,
and define a substitute only for the lacking entities".
> 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
Uuh. As you already noted yourself, the danger here with these approaches
is that when you link a file compiled with the original <stdint.h> and a
file compiled with our substitute, mismatch can occur. For example, a function
taking a int_fast8_t * argument.
I've once debugged a program where a header file declared a variable
of type
int (*) (const char *, struct stat *)
and part of the program was compiled with _FILE_OFFSET_BITS=64
(implying stat := stat64) and another part of the program without it.
I don't want to debug similar mistakes again.
> 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. :-)
Ouch, I didn't notice that requirement. Thanks.
Bruno
