Skip to content
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

[charconv.from.chars] Ambiguous specification of floating-point rounding #6730

Open
zygoloid opened this issue Dec 12, 2023 · 2 comments · May be fixed by #6833
Open

[charconv.from.chars] Ambiguous specification of floating-point rounding #6730

zygoloid opened this issue Dec 12, 2023 · 2 comments · May be fixed by #6833
Labels
lwg Issue must be reviewed by LWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.

Comments

@zygoloid
Copy link
Member

[charconv.from.chars]/6.4 says:

In any case, the resulting value is one of at most two floating-point values closest to the value of the string matching the pattern.

This is ambiguous. It could mean either:

  1. The resulting value is the implementation's choice of one of a set of values, and that set contains the two values closest to the value of the string.

  2. The resulting value is the implementation's choice of one of a set of values, and that set contains all values that are closest to the value of the string (of which it turns out there can be up to two).

I think the normal English interpretation would be (1), but the intended interpretation is actually (2).

(Under (1), the string "1.0" can produce the value one ULP less than 1.0 or it can produce 1.0, and the string "1.00<lots of 0s>1" can produce those same two values, because the value one ULP less than 1.0 is closer to that string than the value one ULP greater than 1.0.)

Perhaps the wording from [conv.double]/2 and [expr.static.cast]/11 can be used instead:

If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values.

@Eisenwave Eisenwave linked a pull request Mar 1, 2024 that will close this issue
@jwakely
Copy link
Member

jwakely commented Mar 2, 2024

This conflicts with the proposed resolution of LWG 3082.

@jwakely
Copy link
Member

jwakely commented Mar 2, 2024

Since we have an open issue, I think I'd prefer to handle it in LWG. Richard's comments can be added to the issue.

@jensmaurer jensmaurer added lwg Issue must be reviewed by LWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking. labels Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lwg Issue must be reviewed by LWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants