Hi Paul, > Also, <inttypes.h> no longer defines > the PRI* and SCN* macros correctly unless the new module > inttypes-pri-scn is used. I expect that many programs are like Emacs > and don't need these these macros or imaxabs etc., so this should be a > win. > ... > > An alternative might be to have a new module, inttypes-h, which provides > > the shell replacement header, and keep inttypes as the module that pulls > > in everything C99 related > > Yes, thanks, that would be more backward-compatible. > Here's a further patch that does that. > > * modules/inttypes-h: New file, containing the old inttypes > but without the PRI* and SCN* stuff.
I don't think it is a good idea to create more modules than necessary for a header file. The users then have to understand which one is the best to choose for them. A 1:1 correspondence between header file and gnulib module, together with a sound and consistent naming convention (and the documentation) is how users pick their modules. We do it for functions like snprintf, though, because code size matters for some projects: They may just want a simple snprintf that support uses of %d, nothing fully POSIX compliant. For this reason, we offer modules 'snprintf' and 'snprintf-posix'. For header files, the code size argument does not apply, only the amount of configure checks. A pretty weak argument for separate modules, IMO. Additionally, in the case of <inttypes.h>, the header file appeared first in ISO C 99 and got the title "Format conversion of integer types". So, really, an <inttypes.h> header without PRI* and SCN* macros is nothing we should offer as an option for gnulib users to pick. One of the problems with the PRI* and SCN* macros (PRI_MACROS_BROKEN) exists only on AIX 4. According to Wikipedia <http://en.wikipedia.org/wiki/AIX>, the successor version, AIX 5.1, is no longer vendor-supported since 5 years ago. That makes it a good candidate for an obsolete module, similar to the other proposed patches I posted today. But this removes only PRI_MACROS_BROKEN from the set of values to be determined at configure time; PRIPTR_PREFIX, INT32_MAX_LT_INTMAX_MAX, INT64_MAX_EQ_LONG_MAX, UINT32_MAX_LT_UINTMAX_MAX, UINT64_MAX_EQ_ULONG_MAX still remain. In summary, I completely disagree with this patch. I see two ways of compromising: a) We could move out the PRI_MACROS_BROKEN to a module inttypes-obsolete. But still to be determined at configure time: PRIPTR_PREFIX, INT32_MAX_LT_INTMAX_MAX, INT64_MAX_EQ_LONG_MAX, UINT32_MAX_LT_UINTMAX_MAX, UINT64_MAX_EQ_ULONG_MAX. Would that be acceptable to you? b) If you reduce the number of inttypes related modules from 3 to 2, and the one which produces an incomplete <inttypes.h> file gets a clearly discouraging name, such as 'inttypes-incomplete' or 'inttypes-dont-use', and that got used only by the 4 function 'imaxabs', 'imaxdiv', 'strtoimax', 'strtoumax', then I could agree to the refactoring. Bruno -- In memoriam Siamanto <http://en.wikipedia.org/wiki/Siamanto>
