Re: [PATCH 0/2] New strfrom functions

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

On 08/24/2016 05:35 PM, Joseph Myers wrote:
> 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.

Should we redact wcstofN* from the list of new _Float128 API too?  Or, is
the existing wcsto* API sufficient reason to keep it?