[committed] libstdc++: Add std::from_chars for floating-point types

Jonathan Wakely jwakely@redhat.com
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?
>
>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
>  <https://sourceware.org/pipermail/libc-help/2020-June/005337.html>
>
>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.
https://movementarian.org/blog/posts/2009-03-14-its-not-just-atol-nicholas/

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
formats.

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
temporary kluge.

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:
>> https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_from_chars_test_cases.hpp#L265
>>
>> 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
>> expected?
>
>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
underflow.




More information about the Gcc-patches mailing list