Re: [PATCH 0/2] New strfrom functions

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 24 Aug 2016, Paul E. Murphy wrote:

> On 08/23/2016 12:58 PM, Joseph Myers wrote:
> > 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.
> 
> Should we also avoid adding wcsfromfN* functions for the same reasons too?

I think so.

The previous discussion of _FloatN functions was saying essentially that 
for each of these functions that you have for float / double / long 
double, you should have a corresponding _FloatN function.  And I think 
that's clearly correct - if we have strfromf_l, we should have 
strfromf128_l; if we have wcsfromf, we should have wcsfromf128.  But it 
wasn't really addressing the question of whether we should have the 
functions for float / double / long double, beyond those in TS 18661-1, at 
all.  And on careful consideration of the minimality of the interface and 
what this implies about how it is intended to be used, it seems 
appropriate not to have the extra functions for any type, just strfromf, 
strfromd, strfroml and the corresponding _FloatN / _FloatNx functions for 
any _FloatN / _FloatNx types supported in glibc.

Wide-string versions of narrow-string functions usually tend to be a 
committee invention - cf. how TR 24731-2 defines some that glibc doesn't 
have, where we do have the narrow string versions.  In this case, the 
committee didn't include such versions, for whatever reason, so it's 
doubtful whether inventing them would really accord with normal glibc 
practice.  *_l may have originated in glibc before being adopted in POSIX 
- at least, I don't think they originated in committee - but the value of 
strfrom_l seeems low.

-- 
Joseph S. Myers
joseph@codesourcery.com