This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 3082. `from_chars` specification regarding floating point rounding is inconsistent

Section: 22.13.3 [charconv.from.chars] Status: Open Submitter: Greg Falcon Opened: 2018-03-12 Last modified: 2020-09-06

Priority: 2

View other active issues in [charconv.from.chars].

View all other issues in [charconv.from.chars].

View all issues with Open status.

Discussion:

P0682R1 added the requirement that `from_chars` use `round_to_nearest` when converting from string, but later text in the section suggests that the implementation has latitude in its choice of rounding logic.

If the intent is merely that the floating point environment should not affect `from_chars` behavior, the rounding-mode text should be weakened. If the intent is to always require `round_to_nearest`, the text suggesting a latitude in rounding logic should be removed.

[2018-03-27 Priority set to 2 after discussion on the reflector.]

[2018-06 Rapperswil Wednesday issues processing]

Status to open; also this needs to say that the intent is to be independent of the floating point environment.

[2018-08-23 Batavia Issues processing]

Marshall to talk to Jens about this

Proposed resolution:

This wording is relative to N4727.

1. Edit 22.13.3 [charconv.from.chars] as indicated:

   >     from_chars_result from_chars(const char* first, const char* last, float& value,
   >                                  chars_format fmt = chars_format::general);
   >     from_chars_result from_chars(const char* first, const char* last, double& value,
   >                                  chars_format fmt = chars_format::general);
   >     from_chars_result from_chars(const char* first, const char* last, long double& value,
   >                                  chars_format fmt = chars_format::general);

   > > -6- Requires: `fmt` has the value of one of the enumerators of `chars_format`.

   > > -7- Effects: The pattern is the expected form of the subject sequence in the `"C"` locale, as described for `strtod`, except that

   > > 1. (7.1) […]

   > > 2. (7.2) […]

   > > 3. (7.3) […]

   > > 4. (7.4) […]

   > > In any case, the resulting value is one of at most two the floating-point values closest to the value of the string matching the pattern, with ties broken according to `round_to_nearest`.

   > > […]