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

["woodard at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #15 from Ben Woodard <woodard at redhat dot com> ---
(In reply to Jonathan Wakely from comment #11)
> (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.

IMHO you have not yet effectively made the case this is related to 2381. Your
assertions are not at all consistent with the text of the change nor have you
explained a couple of other lines of argument that I've presented. 

The note specifically says that:

and this is indeed true, for many strings:

assert(is_same("0"));
<snip>
but not for others
assert(is_same("0xABp-4")); // hex float
<snip>
These are all strings that are correctly parsed by std::strtod, but not by the
stream extraction operators. They contain characters that are deemed invalid in
stage 2 of parsing.

If we're going to say that we're converting by the rules of strtold, then we
should accept all the things that strtold accepts.
<snip>

That seems extremely clear to me. What is not clear about that intention?

Never the less since we are in the process of clarifying the standard, I think
that it should be completely obvious that there should be symmetry between
values written using the hexfloat stream modifier should be able to be read in
by the stream.

Logically having the ability to read numbers in <integral>.<fractional> as well
as both normalized non-normalized scientific notation in both decimal and
hexadecimal would be optimal. This would lead six variations of numbers:
100.123
1234.456e89
1.234456E92
0x100.123
0x123.456p90
0xabp-4

of all those the least justifiable would be: 0x123.456p90 because it is a kind
of hybrid of scientific notation and the <integral>.<fractional> numerical
representation and it is probably unlikely that it will ever be used.
Non-normalized scientific notation was sometimes used in some kinds of
engineering where it helped remind people of the precision of the measured
values but I haven't seen it used that way in quite some time and in all the
cases where it was used, it was always decimal rather than hex.