From: Matt Borland (matt_at_[hidden])
Date: 2024-01-17 06:22:09
> Docs state "non-allocating", yet grepping for malloc
> in the source code yields a couple of results in the
> from_chars implementation for floats. Could you
> please explain the reason behind this?
There are 2 uses of malloc. 1 is behind BOOST_CHARCONV_DEBUG used for printing 128-bit integer strings in ryu_generic_128. The other could in an extreme edge case be hit by the user. It is used in a fallback routine in case of unsuccessful 80 or 128 bit long double conversions in from_chars. If the conversion is unsuccessful on first attempt, and the string is more than 1024 bytes then we need to malloc to avoid a buffer overrun. The rationale for malloc is that it won't throw of failure.
>
> Also, from the docs for from_chars for floating points:
>
> "On std::errc::result_out_of_range we return ±0 for
> small values (e.g. 1.0e-99999) or ±HUGE_VAL for
> large values (e.g. 1.0e+99999) to match the handling
> of std::strtod"
>
> What's the rationale for deviating from the standard here?
>
There is an open issue with LWG here: https://cplusplus.github.io/LWG/lwg-active.html#3081. The standard for <charconv> does not distinguish between underflow and overflow like strtod does. Let's say you are writing a JSON library and you replace strtod with charconv for performance reasons. Charconv returns std::errc::result_out_of_range on some conversion. Now what? You would have to parse the string again yourself to figure out which of the four possible reasons you got std::errc::result_out_of_range. Charconv already had this information but could not give it to you. By implementing the resolution to the LWG issue that matches the established strtod behavior I think we are providing the correct behavior without waiting on the committee. Andrzej did bring this up as well, and a macro BOOST_CHARCONV_STD_ERANGE was added to match what the standard says today.
Please let me know if you have any additional questions.
Matt