[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:39 --- *** Bug 45279 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||kohlhz at t-online dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #15 from paolo dot carlini at oracle dot com 2010-08-29 10:23 --- *** Bug 45442 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||eric dot buchlin at ias dot ||u-psud dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #1 from pcarlini at suse dot de 2006-06-05 21:16 --- This is not a bug, but standard conforming behavior (have a look to the specific sections in 22_locale describing in detail the parsing steps and the grammar). I'm even more sure about that because we discussed the issue face-to-face with Martin Sebor (Roguewave) in Berlin and we agreed that this is something that, probably, it would be nice to have (at performance cost). If you want please forward to the LWG a detailed DR, otherwise it's in my agenda anyway... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-05 22:39 --- I don't think I agree. 27.6.1.2.2 says: As in the case of the inserters, these extractors depend on the locales num_get<> (22.2.2.1) object to perform parsing the input stream data. The conversion occurs as if performed by the following code fragment: 22.2.2.1.2/5 says: For conversions to a floating type the specifier is %g. And then in the C standard: 7.19.6.2/12: a,e,f,g Matches an optionally signed floating-point number, infinity, or NaN, whose format is the same as expected for the subject sequence of the strtod function. The corresponding argument shall be a pointer to floating. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #3 from pcarlini at suse dot de 2006-06-05 22:45 --- (In reply to comment #2) > I don't think I agree. > 27.6.1.2.2 says: > As in the case of the inserters, these extractors depend on the locales > num_get<> (22.2.2.1) object to perform > parsing the input stream data. The conversion occurs as if performed by the > following code fragment: Read in detail Stage 2, 22.2.2.1.2, p8, + the grammar in 22.2.3.1, p2. + Icc (Dinkum) + Rogueware (in the person of Martin) agree. Really, given the current standard we cannot parse that. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-05 22:49:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-05 22:48 --- (In reply to comment #3) > Read in detail Stage 2, 22.2.2.1.2, p8, + the grammar in 22.2.3.1, p2. + Icc > (Dinkum) + Rogueware (in the person of Martin) agree. Really, given the > current > standard we cannot parse that. Wait then 22.2.2.1.2/8 conflicts with 22.2.2.1.2/5 and 22.2.2.1.2/5 should be removed as such it is incorrect as it does not implement strlod as the C standard says it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-05 22:49 --- Please take this up with the C++ standard since the two stages conflict. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #6 from pcarlini at suse dot de 2006-06-05 22:55 --- (In reply to comment #5) > Please take this up with the C++ standard since the two stages conflict. 22.2.2.1.2, p5, does not conflict, because the conversion using %g happens at the end of Stage 2, p9, on the accumulated chars, + there is the grammar, in 22.2.3.1. If, in any case, you think this is matter for a DR (vs a standard enhancement targeted at C++03), then file it, you are not less entitled than me, there is no reason to keep the issue open here, given the C++03 standard that we (all) are implementing. -- pcarlini at suse dot de changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #7 from pcarlini at suse dot de 2006-06-05 22:57 --- (In reply to comment #6) > (In reply to comment #5) > > Please take this up with the C++ standard since the two stages conflict. > > 22.2.2.1.2, p5, does not conflict, because the conversion using %g happens at > the end of Stage 2, p9, on the accumulated chars, Sorry, I really meant Stage 3, p11. Only a detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-05 23:04 --- (In reply to comment #6) It just seems bogus that it says %g and then goes on to do something different and not to take into account that strlod is allowed more than just the characters specified. The other problem I see with the current specification is what happens if you have one of the other UTF-8 number systems also, it seems like it is going to break at the same time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #9 from pcarlini at suse dot de 2006-06-05 23:15 --- (In reply to comment #8) > (In reply to comment #6) > It just seems bogus that it says %g and then goes on to do something different > and not to take into account that strlod is allowed more than just the > characters specified. Maybe. But what do the specifications of strtod **exactly** say in C90 (the reference for C++03)? > The other problem I see with the current specification is what happens if you > have one of the other UTF-8 number systems also, it seems like it is going to > break at the same time? Remember the widening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #10 from ian at airs dot com 2006-06-06 04:11 --- In C90 strtod does not say anything specifically about "inf", etc. However, it does say: In other than the "C" locale, additional implementation-defined subject sequence forms may be accepted. In any case, to me this is a quality of implementation issue. A good implementation will accept "inf", "infinity" and "nan". The fact that C99 explicitly accepts them seems sufficient justification to me. If necessary we can act otherwise if POSIXLY_CORRECT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #11 from pcarlini at suse dot de 2006-06-06 09:36 --- (In reply to comment #10) > In C90 strtod does not say anything specifically about "inf", etc. However, > it > does say: > > In other than the "C" locale, additional implementation-defined subject > sequence forms may be accepted. > > In any case, to me this is a quality of implementation issue. A good > implementation will accept "inf", "infinity" and "nan". Honestly, given also all the text in the C++03 standard I do not agree: currently we are not entitled to parse such strings, because they are not conforming to the grammar and to the text of Stage2. We must fail (as all the other implementations I'm aware of are doing). If you disagree, please file the issue as a DR, but... The fact that C99 > explicitly accepts them seems sufficient justification to me. Sure, that is a very meaninful enhancement, which falls in the C99-compatibility area (already very active, see all the material coming from TR1) and should (will) be discussed in the context of the next standard (C++0x). More exactly, I reported already that the issue is known by Martin at least (I trust him about this section of the standard), but at this stage the policy is that reporting DRs for new features is not the best way to proceed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #12 from ian at airs dot com 2006-06-06 22:18 --- At this web page: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm I see this: "The formatted input functions shall support the additional conversion specifications specified in C99 subclause 7.19.6.2." So if my understanding is correct, this facility is already in TR1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #13 from pcarlini at suse dot de 2006-06-06 22:36 --- (In reply to comment #12) > At this web page: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm > > I see this: > > "The formatted input functions shall support the additional conversion > specifications specified in C99 subclause 7.19.6.2." Interesting, in particular the followint note. > So if my understanding is correct, this facility is already in TR1. Well, not really. The text in TR1 is about the facilities provided in and . The text in 22_locale should then be consistently updated, at minimum the specifications for Stage2 and the grammar made consistent. But probably the entire parsing must be heavily reworked, there are long standing and nasty defects proper. More generally, the entire C++0x standard will be more careful with NaNs, infinities and such, not mentioned at all in C++03 (similarly to C90). That is causing problems in other unrelated areas (while we are writing people are discussing on the reflector containers vs NaNs...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904