[committed] libstdc++: Add std::from_chars for floating-point types
Mon Aug 3 12:30:28 GMT 2020
On 03/08/20 13:47 +0200, Florian Weimer wrote:
>* Jonathan Wakely:
>>>What seems to be missing is a function that takes an explicit buffer
>>>length. A static reference to the C locale object would be helpful as
>>>well, I assume.
>> How expensive is it to do newlocale("C", nullptr), uselocale, and
>freelocale does nothing in this situation. newlocale has a bunch of
>conditional branches to detect this situation. uselocale has fewer
>branches, but has more memory accesses.
>At least there's no locking involved. (But I believe uselocale is
>thread-unsafe regarding setlocale in the glibc implementation or
>something like that.)
>>>Maybe this is sufficiently clean that we can export this for libstdc++'s
>>>use? Without repeating the libio mess?
>> I think we could beat strtod's performance with a handwritten
>> implementation, so I don't know if it's worth adding glibc extensions
>> if we would stop using them eventually anyway.
>I was reminded of this query:
> Robustly parse string to unsigned integer (strtoul?)/docs
>It suggests to me that we need better interfaces.
Yes, the ISO C interfaces for this are poor.
Their error reporting is tricky. You have to check a combination of
the return value, the endptr argument, and errno.
They are too general. strtod is a single function that parses three
different number formats, with no way to restrict it only one of those
They require null-terminated strings, making them unsuitable for
certain uses e.g. a byte sequence containing several Pascal-style
length-prefixed strings like "\x05123.4\x351".
They're locale-dependent, which is not useful for machine-readable I/O
where the format of numbers must not be localized e.g. JSON.
And strtoul accepts negative numbers (srsly?!)
C++ has decided to ignore these C functions and has defined better
ones. The fact that libstdc++ currently uses strtod internally is a
Replicating the C++ API in glibc might be useful for C devs, but to be
useful for libstdc++ we'd need to copy the code into libstdc++ itself
so we could use it for targets using musl, newlib, BSD, mingw etc.
>> I also noticed some strings give an underflow error with glibc's
>> strtod, but are valid for the Microsoft implementation. For example,
>> this one:
>> Without the final '1' digit glibc returns DBL_MIN, but with the final
>> '1' digit (so a number larger than DBL_MIN) it underflows. Is that
>I don't know. I think you should bring this up on libc-alpha.
Joseph answered this part, clarifying that glibc is correct to report
More information about the Gcc-patches