Hi Simon, > > This would cause problems in libintl. The intl/ directory, when shipped > > as part of a package that used gettextize, should not create its own copy > > of stdint.h. > > Btw, why not? It seems it could create it under, say, intl/gl/
It could, certainly. But packages that include the intl/ subdirectory should not be punished with lots of configure tests. Also, this mode of shipping libintl should probably go away. It's so much better to use it as a shared library. Therefore I don't want to spend much time on autoconfiguration changes of intl/. > > vasnprintf.c, which > > depends on xsize.h, which needs a definition of SIZE_MAX. For this reason, > > xsize.h arranges to get a correct SIZE_MAX in the cheapest possible way. > > Ok, that makes sense. I note that xsize.h does not include size_max.h. > Should it? Perhaps size_max.h does not make sense. xsize.h contains the equivalent of size_max.h inlined: /* Get SIZE_MAX. */ #include <limits.h> #if HAVE_STDINT_H # include <stdint.h> #endif Hard to say whether size_max.h is still worth it, except for the good comments... > How about clarifying the intentions behind the size_max module a bit > better? It seems most applications will want to include stdint.h and > depend on the stdint gnulib module, rather than using the gnulib > size_max module. Exactly, right. The size_max.h file is from 2005, and since 2006 we have a working <stdint.h> replacement, so most modules meanwhile rely on that. Bruno
