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.