From: John Zaitseff <J.Zaitseff@zap.org.au>
To: Gnulib discussion <bug-gnulib@gnu.org>
Subject: Re: Adding strfmon(3) to Gnulib?
Date: Sat, 11 Aug 2018 14:31:50 +1000 [thread overview]
Message-ID: <20180811043150.eka5xwny6ebf2o4y@zap.org.au> (raw)
In-Reply-To: <20180723091714.4hoqu5op7puxchm3@zap.org.au>
Hi, all,
I wrote back on 23rd July:
> [...] Is it worth adding strfmon(3) and possibly strfmon_l(3) for
> those systems that do not have it? I'm thinking primarily
> OpenBSD, even in the latest version. This OS does not have
> <monetary.h> either.
and
> [...] If the Gnulib maintainers are agreeable, I'll try setting
> aside some time in the next couple of weeks to come up with a
> suitable patch [...]
Just to let you know that I've started work on replacement strfmon
and strfmon_l functions. 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>.
2. Create a strfmon module to provide the strfmon() function. This
will depend on monetary-h. I will almost certainly implement the
function using GNU C Library (glibc) source code. I'll look at
how the glob, getopt-gnu and getopt-posix modules do it... or
should I be looking at other "model" modules?
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. Again, I'll be using current glibc code.
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.
5. Develop appropriate tests for all of the above.
6. Update documentation in doc/posix-headers and doc/posix-functions
to suit.
7. Add appropriate lines into MODULES.html.sh and config/srclist.txt.
Anything major I've forgotten? And yes, I've read Chapter 4 of the
GNU Gnulib manual--in fact, I've read the whole document based on
the current git sources :-) I expect the patches will need to go
through a few iterations on this mailing list before being merged,
of course. I've also signed the copyright assignment papers and
sent those off.
Yours truly,
John Zaitseff
--
John Zaitseff ,--_|\ The ZAP Group
Phone: +61 2 9643 7737 / \ Sydney, Australia
E-mail: J.Zaitseff@zap.org.au \_,--._* http://www.zap.org.au/
v
next prev parent reply other threads:[~2018-08-11 8:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 9:17 Adding strfmon(3) to Gnulib? John Zaitseff
2018-07-23 10:31 ` Paul Eggert
2018-07-23 10:41 ` John Zaitseff
2018-08-11 4:31 ` John Zaitseff [this message]
2018-08-12 20:13 ` Bruno Haible
2018-08-12 22:24 ` John Zaitseff
2018-08-12 22:35 ` Bruno Haible
2018-08-12 22:21 ` Bruno Haible
2020-09-27 10:33 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180811043150.eka5xwny6ebf2o4y@zap.org.au \
--to=j.zaitseff@zap.org.au \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).