https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #8 from Heinz Kohl <koh...@t-online.de> ---
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).
