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).
