Hi John, > My current thinking, before I get too far > into the task, is to: > > 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'. > 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. > This > will depend on monetary-h. I will almost certainly implement the > function using GNU C Library (glibc) source code. Sounds good. > I'll look at > how the glob, getopt-gnu and getopt-posix modules do it... or > should I be looking at other "model" modules? These are good examples, to look at, yes. > 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'. > 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. > 5. Develop appropriate tests for all of the above. Yes. It is just a bit tedious to write tests, but not hard. > 6. Update documentation in doc/posix-headers and doc/posix-functions > to suit. Yep. > 7. Add appropriate lines into MODULES.html.sh and config/srclist.txt. Yes, good. > I've also signed the copyright assignment papers and > sent those off. Good! This is essential. Bruno
