Re: Adding strfmon(3) to Gnulib?

[Bruno Haible]

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