[Bug libstdc++/27904] operator to floating point variable does not support inf, infinity, or nan

2010-08-29 Thread paolo dot carlini at oracle dot com


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

2010-08-13 Thread paolo dot carlini at oracle dot com


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

2006-06-06 Thread pcarlini at suse dot de


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

2006-06-06 Thread ian at airs dot com


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

2006-06-06 Thread pcarlini at suse dot de


--- 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 cstdio
and stdio.h. 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



[Bug libstdc++/27904] operator to floating point variable does not support inf, infinity, or nan

2006-06-05 Thread pcarlini at suse dot de


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

2006-06-05 Thread pinskia at gcc dot gnu dot org


--- 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 locale’s
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

2006-06-05 Thread pcarlini at suse dot de


--- 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 locale’s
 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

2006-06-05 Thread pinskia at gcc dot gnu dot org


-- 

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

2006-06-05 Thread pinskia at gcc dot gnu dot org


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

2006-06-05 Thread pinskia at gcc dot gnu dot org


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

2006-06-05 Thread pcarlini at suse dot de


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

2006-06-05 Thread pcarlini at suse dot de


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

2006-06-05 Thread pinskia at gcc dot gnu dot org


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

2006-06-05 Thread pcarlini at suse dot de


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

2006-06-05 Thread ian at airs dot com


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