John Zaitseff wrote: > > 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
Good. That's the one I would be favouring too. > 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? The '-gnu' suffix tells the users to expect GNU / glibc-like behaviour, with the same function signatures. If the signature is different, for example if you create an additional entry point which takes the currency_symbol, the positive_sign, and the negative_sign as explicit arguments, then you would give it a different function name (xstrfmon, nstrfmon, or similar), and that function would likely go into a separate module with corresponding name. > > > 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" Adding function declarations to a .h file is not considered a backward compatibility problem. It rarely causes actual problems. Bruno
