[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ben Woodard from comment #10)
> Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775
> 
> My reading of:
> https://wg21.link/lwg2381
> 
> is that if the first part of the number includes a '.' then the portion
> after the 'p' or 'P' is not part of the number and is left in the string.
> The example is 
> 0x1a.bp+07p
> 
> So I believe that your assertion that 2381 applies in this situation is not
> accurate. This example refers to the number: 26.6875 (16+10+11/16) and
> because there is already a hexadecimal point '.' separating the integral
> portion from the fractional portion the 'p' is not part of the number.

That just means it's a bad example in the proposed resolution, but the example
is not normative anyway.

> However, if the number was: "0x1abp+07p" (note the absence of the '.') then
> the number would be: in the normal hexfloat format and refer to 1752839.0
> leaving the trailing 'p' in the stream.

But in all versions of the C++ standard the first 'p' is not accumulated in
Stage 2 of the num_get::do_get call, and so the string passed to strtod is
"0x1ab" and nothing more. That's what LWG 2381 is about: the list of atoms
needs to be extended to include 'p' and 'P' so that the fractional portion can
be accumulated and passed to strtod.