Paul Eggert wrote: > the same compiler, with > different options) might disagree about the standard types. So it's > not an issue of solving the problem in general; it's an issue of how > likely it would occur in practice, with the approach I proposed.
We are not the only people providing a <stdint.h> substitute. There are at least two other ones, plus the system <stdint.h>. The problem will occur as soon as these types int_fastN_t are used in header files and - through different -I options - the compiler will not always pick the same <stdint.h>. Different -I options in different directories of a large package are quite frequent. It may simply be a -I/usr/include which causes the system's <stdint.h> to take precedence. By not redefining types that are already defined by the system, I can not avoid clashes between our <stdint.h> substitute and the two other portable ones, but at least I can avoid clashes with the system headers. I'll add a warning to the stdint.h substitute, not to use the int_fastN_t types in header files. Bruno
