https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123078
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|std::from_chars handles |[LWG 3081] std::from_chars
|signedness of zero in |handles signedness of zero
|underflow inconsistently |in underflow inconsistently
|with floating-point |with floating-point
|literals |literals
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jan Schultke from comment #9)
> Even if one interpreted "range of representable values" as only
> including finite values,
As I said in the issue, and as I quoted above, -1000 is outside the range of
possible exponents for float. It has nothing to do with only including finite
values, nobody has suggested that.
The current standard seems very clear that if ec is set in the result, then
value is not modified:
"If the parsed value is not in the range representable by the type of value,
value is unmodified and the member ec of the return value is equal to
errc::result_out_of_range. Otherwise, value is set to the parsed value"
Since libstdc++ is setting ec, it's correct to not modify the value. Your
example is wrong because it fails to check the result for an error.
What's under dispute is when ec should be set. Libstdc++ currently takes the
interpretation that if strtod sets ERANGE, then from_chars sets
errc::out_of_range. That doesn't seem indefensible to me.
As I said in comment 4, the proposed resolution of 3081 might be a better
approach. Interpreting 1e-1000 as within the representable range (as MSVC and
libc++ could be doing) might also be a better approach. But libstdc++ follows
strtof/strtod/strtolf and sets errc::out_of_range in ec. And if that's done,
then the value must be unmodified.
If the libstdc++ interpretation should not be allowed, the standard should be
clarified. Which is LWG 3081.
Currently the standard requires us to either report success but with an
inaccurate number, or report failure with no number at all. As 3081 says,
strtod is different, it allows reporting ERANGE *and* returning a value on
overflow and underflow.
You can argue all you like, but there's an open issue on **exactly** this
topic, and I don't plan to change libstdc++ until it's clear how that issue
will be resolved, so that we don't have to change it twice.
