https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Ben Woodard from comment #15) > IMHO you have not yet effectively made the case this is related to 2381. Read comment 14 again. > 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. I can't follow your lines of argument. > That seems extremely clear to me. What is not clear about that intention? It's just what the issue submitter said, it's not the view of the committee. The issue is still open, so until it's resolved the standard still has effectively the same spec as it had in 1998. C++98 didn't support parsing hex floats because it was based on C89 which didn't support them either. We need to fix the C++ standard to make it clear that parsing hex floats should work, and that's what 2381 is about. This bug report is complaining that parsing hex floats doesn't work with libstdc++. See the relation now? > [...] > of all those the least justifiable would be: 0x123.456p90 because it is a > [...] That's irrelevant, C says it's valid, and strtod parses it, so C++ should too. The open question is how the C++ part of the library should accumulate input characters for the call to strtof/strtod/strtold, because everything else is handled by strtof/strtod/strtold. For the third time, I want to wait and see how the committee resolves the issue before changing our implementation, because the changes will not be backwards compatible and can change the behaviour of existing user code.
