Re: [PATCH 0/2] New strfrom functions

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 23 Aug 2016, Gabriel F. T. Gomes wrote:

> The following patches add the functions strfromd, strfromf, and strfroml, as
> well as their wide character counterparts, wcsfromd, wcsfromf, and wcsfroml.

What is the rationale for (a) the *_l functions and (b) the wide-character 
functions?  Patch submissions need to include self-contained rationale for 
such API additions.

What's the locale dependence anyway?  Is it just the decimal point 
character?  You don't seem to have any tests of strfrom*_l, and the 
strfrom test sets only LC_CTYPE not LC_NUMERIC meaning it doesn't exercise 
different decimal point values.

The argument for not having those extra functions, just the three standard 
ones, is that the strfrom API is deliberately designed to be minimal.  It 
doesn't include any of the flags that are available with snprintf, or the 
option to specify field width, or the option to use '*' for precision.  
That is, the idea of the API is: the floating-point aspects of the 
conversions are tricky and specialized, especially when you want correctly 
rounded results, but once you've got a result rounded to the correct 
number of digits, everything else is just routine string manipulation from 
there.  Converting a narrow string to a wide one is certainly easy, so in 
line with that principle you don't need the wcs* functions (and avoiding 
them avoids questions about whether the API follows snprintf or swprintf).  
And we've said before for some suggestions of *_l functions that we don't 
need *_l versions of all functions because for ones where it's likely to 
be less useful it's OK to expect users to use uselocale to set the 
thread-locale locale before calling a function.

So I think there's actually a strong case for just adding the three 
standard functions.  Users wanting to use grouping or outdigits would need 
to manipulate the results of strfrom anyway; it doesn't seem bad for those 
wanting a decimal point from a locale other than the current one to need 
to do so or to use uselocale, or for users wanting wide strings to need to 
convert.

(Testing that those three functions do use the locale-specific decimal 
point, like snprintf, is still desirable.)

-- 
Joseph S. Myers
joseph@codesourcery.com