* 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.
> 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.
Thanks,
Florian
