Re: Adding strfmon(3) to Gnulib?

[John Zaitseff]

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: address@hidden   \_,--._*   http://www.zap.org.au/
                                      v