-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
behavior in case of overflow/underflow differs from std::from_chars specification? #120
Comments
The from_chars supports various number types, including integer types. For integer types, there is a finite range. I covered my stance with respect to this issue in the following PR: |
I think an LWG issue is warranted, since we have two reasonable but conflicting interpretations of the standard. |
Agreed. However, this assumes that the user only cares about the best representation of the input in a A more interesting value is 1e40. It does not fit in a binary32, but does in a binary64. A user may wish to use 32-bit code if the values fit and 64-bit code otherwise. A parser that returns infinity on overflow makes such approaches much more difficult to write. The opposite is easier. Same argument for 64-bit overflow as some platforms offer 80-bit floats and of course variable-precision libraries exist. I'd also argue that a C++ library should match the behavior of the C++ standard library, not Python, JavaScript, or Swift. AFAIK all floating-point parsers in the C and C++ standard libraries have a way to distinguish overflow. Heck, you can easily do both. The error code is separate from the return value, so just return infinity (or -infinity, or whatever) but still set |
@alugowski That's reasonable. Pull request invited. I don't consider the current behaviour incorrect but if someone wants to contribute the code for the functionality that @alugowski described, then we will merge it. |
PR submitted with the behavior as I described above: #189 The main difference from @pppalka 's patch is that the check is one line lower to still return the best match value. |
Actually I think I'll add a comment to https://cplusplus.github.io/LWG/issue3081 |
I will close this issue given that I just merged #189 |
When the parsed value is outside the representable range, such as on input "1e-10000" and "1e+10000", it seems fast_float::from_chars sets the 'value' output parameter to 0 and infinity respectively and returns std::errc{}.
But the specification for std::from_chars (http://eel.is/c++draft/charconv.from.chars#1) says:
It this deviation from the C++ standard intended?
When integrating fast_float into libstdc++, we adjusted this behavior with the following patch: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=40b0d4472a2591cf27f3a81aa3fba57dc4532648
The text was updated successfully, but these errors were encountered: