Hi, Bruno et al., > > 1. Rename the monetary module to monetary-h and extend it to > > provide an actual replacement for <monetary.h>, a la > > <glob.h>. > > This is not needed. The 'monetary' module exists to provide a > substitute <monetary.h>. We use the suffix '-h' in module names > only for disambiguation when there is also a function with the > same name. So it's 'stdlib', 'unistd', but 'glob-h' and > 'fnmatch-h'.
I see. I was more thinking along the lines that current users of "monetary" will see a changed behaviour that they don't want. But I'm happy to keep the <monetary.h> generation in the "monetary" module. > > 2. Create a strfmon module to provide the strfmon() function. > > As indicated in http://austingroupbugs.net/view.php?id=1199, there > is a conflict between POSIX compliance and usability in strfmon. > Do you want > a) a module 'strfmon' that merely ensure _some_ implementation > of strfmon is present? > b) a module 'strfmon-posix' that ensures a POSIX compliant > strfmon is visible? (This would mean to override a usable > implementation with an unusable one, on glibc systems.) > c) a module 'strfmon-gnu' that ensures a glibc compatible > strfmon? This one would be usable, but not POSIX compliant. I think option (c) is the one I'm planning: as you note in the bug report, different systems return different results; I myself noted that Solaris returns different width results, which can throw off formatting in some programs (I don't have access to AIX or even macOS, so I haven't tested those). In my own little game of Star Traders, I wrap around strfmon() for the C or C.UTF-8 locale to make it act as if localeconv()->currency_symbol was "$" and negative_sign was "-". In the case of option (c), should the modules still be called "strfmon" and "strfmon_l"? Or is the "-gnu" suffix the way to go? > > 3. Rework the existing strfmon_l module to provide a replacement > > strfmon_l() function instead of just working around bugs in > > old versions of glibc. > > This is a code size trade-off. If there's just one bug to work > around, you can continue to use that. However, when there are 3 or > more bugs, the combined workarounds typically exhibit complicated > code, so in this case it's OK to use a direct implementation. This > is also what we do for 'vasnprintf'. It's more that glibc implements strfmon() using strfmon_l() :-) Hence it saves me rewriting strfmon(). > > 4. Create a replacement monetary module that depends on monetary-h, > > strfmon and strfmon_l, with a message that monetary is now > > obsolete and that programmers should use strfmon and/or > > strfmon_l. > > I don't see what such a module would obtain. If a gnulib user > wants to use strfmon(), they will specify the module 'strfmon'. If > they want to use strfmon_l(), they will specify the module > 'strfmon_l'. We don't have a module for "all functions declared > in <stdlib.h>" either. I was thinking along the lines of backwards compatibility for Gnulib users of the current "monetary", but hopefully they'll read NEWS and Changelog. I'm going away for a week, with limited Internet access, but I'll do a bit of work in the evenings on all of this. Yours truly, John Zaitseff -- John Zaitseff ,--_|\ The ZAP Group Phone: +61 2 9643 7737 / \ Sydney, Australia E-mail: j.zaits...@zap.org.au \_,--._* http://www.zap.org.au/ v
