[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #32 from Jonathan Wakely --- None of the implementations interpret it your way: https://godbolt.org/z/avPsbYn94 It's still completely off topic in this bug report, please take it to the mailing list or std-discussion or somewhere else.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #31 from M Welinder --- I see. That is interestingly different from what https://en.cppreference.com/w/cpp/utility/from_chars.html says. paraphrased: same as strtod, but 0x not allowed when hex format is explicitly specified.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #30 from Jonathan Wakely --- Correct, that's how std::from_chars works. It never parses a prefix, and you need to use the hex format if you want to parse hex floats. There is no bug with from_chars, and it's nothing to do with this bug report for istream. https://eel.is/c++draft/text#charconv.from.chars-6.4
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #29 from M Welinder ---
but not with a 0x prefix (And general format):
#include
#include
#include
int main()
{
std::string_view str = "0x1.abcp4";
double d;
std::from_chars(str.data(), str.data() + str.size(), d);
std::cout << d << '\n';
std::cout << 0x1.abcp4 << '\n';
return 0;
}
0
26.7344
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #28 from Jonathan Wakely ---
It certainly does read hex floats.
#include
#include
#include
int main()
{
std::string_view str = "1.abcp4";
double d;
from_chars(str.data(), str.data() + str.size(), d, std::chars_format::hex);
std::cout << d << '\n';
std::cout << 0x1.abcp4 << '\n';
}
26.7344
26.7344
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 M Welinder changed: What|Removed |Added CC||terra at gnome dot org --- Comment #27 from M Welinder --- from_chars is now available and it does not (as of 15.1) read hex floats. Do you want that as a separate bug?
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.5|---
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.4|13.5 --- Comment #26 from Jakub Jelinek --- GCC 13.4 is being released, retargeting bugs to GCC 13.5.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #25 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Richard Biener changed: What|Removed |Added Target Milestone|13.2|13.3 --- Comment #24 from Richard Biener --- GCC 13.2 is being released, retargeting bugs to GCC 13.3.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Richard Biener changed: What|Removed |Added Target Milestone|13.0|13.2 --- Comment #23 from Richard Biener --- GCC 13.1 is being released, retargeting bugs to GCC 13.2.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |13.0 Status|NEW |ASSIGNED
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |NEW
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Dvir Yitzchaki changed: What|Removed |Added CC||dvirtz at gmail dot com --- Comment #22 from Dvir Yitzchaki --- any update on this now that CWG 2381 has been approved? source: https://wg21.link/lwg2381
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #21 from Paul A. Bristow --- I also note that https://en.cppreference.com/w/cpp/io/manip/fixed Notes Hexadecimal floating-point formatting ignores the stream precision specification, as required by the specification of std::num_put::do_put. https://en.cppreference.com/w/cpp/locale/num_put/put Additionally, if floatfield != (ios_base::fixed | ios_base::scientific), then (since C++11) precision modifier is added, set to str.precision() "When formatting a floating point value as hexfloat (i.e., when floatfield == (std::ios_base::fixed | std::ios_base::scientific)), the stream's precision is not used; instead, the number is always printed with enough precision to exactly represent the value." (since C++11) but this is not what MSVC currently 16.7.0.Preview 3 is implementing as noted https://developercommunity.visualstudio.com/content/problem/520472/hexfloat-stream-output-does-not-ignore-precision-a.html *It would be extremely unfortunate if various compilers implemented this differently.* I see no case for precision to change the output from std::hexfloat because it specifies a *decimal* precision, not a hexadecimal one. std::hexfloat output should always be enough precision to *exactly represent the value*, however large. It would be nice if std::showpoint could also respect output of trailing zeros, so that the default std::showpoint output displays neat columns, and that std::noshowpoint made output with minimum size (for example, minimizing serialized data). (In passing, I note that std::scientific always includes (often many) trailing zeros, ignoring showpoint. Changing this would be logical but a breaking change.)
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #20 from Jonathan Wakely --- I'll ask the new LWG chair to bump the issue.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #19 from Maxim Egorushkin --- (In reply to Jonathan Wakely from comment #17) > At this time LWG 2381 is still open. Until the proposed fix (or some other > fix) is resolved by making a change to the draft standard, I do not want to > change libstdc++. May be enable hexfloat round-trip if a user defines a macro? The standards often follow existing practice, waiting on the standard may lead to a deadlock.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Paul A. Bristow changed: What|Removed |Added CC||pbristow at hetp dot u-net.com --- Comment #18 from Paul A. Bristow --- Working on test for Boost.Multiprecision UDTs, I have just stumbled on this, expecting loopback to 'just work' as it does on Clang libc++ and MSVC. LWG 2381 is still (currently open) and seems to have stalled? Is there any way to get this resolved for GCC libstd++?
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #17 from Jonathan Wakely --- For the avoidance of doubt: C++98 did not support reading hex floats from an istream. Libstdc++ still follows the C++98 spec, so does not read hex floats. "0x1" is read as "0". "0x1p1" is also read as "0". LWG 2381 is a (currently open) issue reported against the standard, saying that the standard is not clear about whether reading hex floats is supposed to work. The proposed fix is to add 'p' and 'P' to the list of atoms, and add examples making it clear what should be parsed. At this time LWG 2381 is still open. Until the proposed fix (or some other fix) is resolved by making a change to the draft standard, I do not want to change libstdc++. When the C++ committee resolves LWG 2381 I will update libstdc++ to implement the new rules.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #16 from Jonathan Wakely --- (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.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #15 from Ben Woodard ---
(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"));
but not for others
assert(is_same("0xABp-4")); // hex float
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.
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 . 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 . 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.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #14 from Jonathan Wakely --- Yes that's expected. It's the same issue. Libstdc++ still follows the C++98 spec which means there is no such thing as a hex float, and so "0x" cannot be the start of a floating point value, it's just "0". There are two parts to support for parsing hex floats: firstly the standard needs to be updated to allow 'p' and 'P' to be accumulated and passed to strtod. Secondly, implementations need to be updated to recognize hex floats (which means parsing numbers beginning with "0x" and also supporting exponents following 'p' or 'P'). As I said in comment 9: "I don't want to change our implementation yet, until the intention of the committee is clear." "We know you can't currently read hex floats using istreams with libstdc++, we know it's a defect in the standard, we're working on it."
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #13 from Heinz Kohl ---
O.k., but following your arguments I'd expect 0xb as result for my second
example 0xb.3590da0e2a06736p-3 (attachment 41578), but it's giving 0, also
stopping at 'x' and not at '.', just as in the first case.
It might be just another case of the same problem, but I'm not sure.
An actual test run:
./a.out
Parsing 0x1P-1022 as hex gives 0
Parsing '0xb.3590da0e2a06736p-3 xyz' as hex gives 0 xb.
(The source code for the second example is:
std::istringstream("0xb.3590da0e2a06736p-3 xyz") >> std::hexfloat >> g >> a
>> b >> c ;
std::cout << "Parsing '0xb.3590da0e2a06736p-3 xyz' as hex gives " << g << ' '
<< a << b << c << std::endl;
)
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #12 from Jonathan Wakely --- (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. No, there's nothing wrong with the example. I don't know how you're interpreting the spec but it seems wrong.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #11 from Jonathan Wakely --- (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.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #10 from Ben Woodard --- 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. 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.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #9 from Jonathan Wakely --- (In reply to Heinz Kohl from comment #8) > o.k., it looks like a flawy definition. Yes, that's why it's being fixed by the standards committee. I don't want to change our implementation yet, until the intention of the committee is clear. > First of all, it would be nice, if you would refer my error message to the > right instance. I don't know what this means. We know you can't currently read hex floats using istreams with libstdc++, we know it's a defect in the standard, we're working on it.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #8 from Heinz Kohl --- o.k., it looks like a flawy definition. First of all, it would be nice, if you would refer my error message to the right instance. It's unclear, what's to do in the meantime. An idea might give, what's a simple C++-user like me would expect in this case(s). That may be one of the following: 1) no change of behavior 2) read is symmetric to write Both together isn't possible. Standards for programming language are imperfect. That's a very known situation in the history of programming languages at least since Algol60 (when I was an implementor). There's no really conforming implementation possible, when the standard is faulty. The difference between a good and a bad implementation is laying not at least in the way to cope with this problem. Usability, not principled implementation is the criterion for a good implementation. The classical considerations are "What seems to be the best work around for users? What's the best work around for me as implementor? What are other implementers doing? Is it better to use implement a mostly restricted manner, or in a mostly wide, or let the user select dependend on an option?". Every of these cases may violate expectations and should be documented therefore. For all these cases it seems to be necessary to document the decision, at least in the user's guide. For many applications it's expected to read exactly the same value as written. Without the possibility to do it with hexfloat, there's no safe base to do that. The only possible way to document floating point values in an exact manner indepently to the internal representation is to use this format, not only, but especially when using multi precision floating point numbers. When there's no possibility to read these values back, this is senseless - more, it looks like a crazy joke. (my workaround: add 64 bits of precision, write decimal, analyze input for values like inf, -inf, nan, else read decimal. It's still inexactly beside a lot more programming and spending much more space and time at runtime).
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #7 from Jonathan Wakely --- (In reply to Ben Woodard from comment #5) > The example code in: http://en.cppreference.com/w/cpp/io/manip/fixed > suggests that this should work. Probably either the behavior or the library > or the example on cppreference should change. The standard does not permit the example to read the hex float, because 'P' is not one of the characters that std::num_get::do_get will accumulate. Implementations which parse that hex float are non-conforming. Again, see comment 1.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #6 from Jonathan Wakely ---
(In reply to Ben Woodard from comment #4)
> Without this Is there a way to read and write floats and doubles accurately
> without the rounding that converting to/from base 10 ends up introducing?
> How are you supposed to use istreams like
>
> printf(“%a”,dbl);
std::cout << std::hexfloat << dbl;
> scanf(“%f, &dbl);
You can't read a hexadecimal float back in using an istream.
C++17 provides std::to_chars and std::from_chars for lossless conversion of
numbers to/from strings, but GCC only supports it for integers so far, not
floats.
> Note that scanf does handle doubles in whatever form they come in.
As do strtof, strtod and strtold.
> Further note that according to stackexchange this works on llvm and other
> libstdc++ implementations.
N.B. There are no other libstdc++ implementations, libstdc++ is the name of
GCC's C++ standard library implementation, not the generic name.
Some cases work with LLVM's libc++, but their support also gives the wrong
result for valid cases that don't involve hex floats:
#include
#include
int main()
{
double d;
char c;
std::istringstream in("1.00f");
in >> d >> c;
assert( d == 1.0 && c == 'f' );
}
This fails with libc++.
> Therefore if the standard is unclear in this area
> maybe it is a topic to be clarified.
See comment 1.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #5 from Ben Woodard --- The example code in: http://en.cppreference.com/w/cpp/io/manip/fixed suggests that this should work. Probably either the behavior or the library or the example on cppreference should change.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #4 from Ben Woodard --- Without this Is there a way to read and write floats and doubles accurately without the rounding that converting to/from base 10 ends up introducing? How are you supposed to use istreams like printf(“%a”,dbl); scanf(“%f, &dbl); Note that scanf does handle doubles in whatever form they come in. Further note that according to stackexchange this works on llvm and other libstdc++ implementations. Therefore if the standard is unclear in this area maybe it is a topic to be clarified.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 Jonathan Wakely changed: What|Removed |Added Status|NEW |SUSPENDED Summary|parsing f stopped after '0' |[DR 2381] parsing f stopped |when reading std::hexfloat |after '0' when reading |>> f; |std::hexfloat >> f; --- Comment #3 from Jonathan Wakely --- It's unclear whether the standard says this should work or not. LWG 2381 argues that it is already implied by the use of strtod, but 'P' cannot be accumulated into an input sequence for strtod, because it's not a valid atom.
