[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding strfmon(3) to Gnulib?
Re: Adding strfmon(3) to Gnulib?
Mon, 13 Aug 2018 08:24:53 +1000
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
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"
> > 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
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.
John Zaitseff ,--_|\ The ZAP Group
Phone: +61 2 9643 7737 / \ Sydney, Australia
E-mail: address@hidden \_,--._* http://www.zap.org.au/