[Bug libstdc++/45280] New: Stream parsing of digit-then-e (with no exponent) now fails

[Bug libstdc++/45280] New: Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

In past versions of the C++ standard library, if I piped a string like "59e"
into a double, it would set the double to '59' and set position of the get
pointer to after the e.  This meant I had to check if the last char read was an
'e' and if so, back up, but that was OK.

Something changed (and I wish I could tell you when, but I don't know--probably
in my upgrade from ubuntu 9.04 to 10.04) so now when I do the same thing, the
stream parser just gets confused, sets the 'fail' bit, and sets the double to
0.  Here's a test program:


#include <sstream>
#include <iostream>
using namespace std;

int main(int argc, char** argv)
{
  stringstream withx, withe;
  withx << "59x";
  withe << "59e";
  double num;
  char cc;
  withx >> num;
  cc = withx.get();
  cout << "From the string '59x', the streamed number is " << num << ", and the
next character is '" << cc << "'" << endl;
  withe >> num;
  cc = withe.get();
  cout << "From the string '59e', the streamed number is " << num << ", and the
next character is '" << cc << "'" << endl;
  cout << "tellg: " << withe.tellg() << endl;
  cout << "tellp: " << withe.tellp() << endl;
  cout << "eof? " << withe.eof() << endl;
  cout << "fail?" << withe.fail() << endl;
  cout << "bad?" << withe.bad() << endl;
}

which outputs:


>From the string '59x', the streamed number is 59, and the next character is 'x'
>From the string '59e', the streamed number is 0, and the next character is
'&#65533;'
tellg: -1
tellp: -1
eof? 0
fail?1
bad?0

Now, ideally, parsing '59e' should behave exactly the same as parsing '59x'--it
would notice that there's no exponent, decide the 'e' wasn't part of the
number, back up, export '59', and the next result of 'get' would return 'e'. 
But barring that, going back to the old behavior of not failing and returning
59, even if the get position is post-e, would be great.

I apologize for not testing this in more recent builds--I did check the
changelog and the list of bug fixes, and didn't find this in there, though I
certainly could have missed it.


-- 
           Summary: Stream parsing of digit-then-e (with no exponent) now
                    fails
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: lpsmith at u dot washington dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2010-08-13 20:15 -------
Yes, this is intended. We even have testcases about that.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2010-08-13 20:23 -------
By the way, if you read 22.2.3.1 in C++98, it's clear that 'e' is *not* just
any other character: after 'e', a sign is optional but at least a digit is
compulsory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

------- Comment #2 from lpsmith at u dot washington dot edu  2010-08-13 20:22 -------
Is the reasoning explained somewhere?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

------- Comment #4 from lpsmith at u dot washington dot edu  2010-08-13 20:34 -------
Yes, exactly!  Which is why the 'e' should not be parsed at all unless there is
an optional sign and a compulsory digit following it.  The 'e' in general is
not compulsory.  '59' is a valid double.

The context is that I am parsing (among other things) chemical reactions.  It
is perfectly valid to have something like:

2EtOH -> EtOHX


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

------- Comment #5 from lpsmith at u dot washington dot edu  2010-08-13 20:56 -------
Followup:  This still fails even if you're trying to pipe it into an integer
and not a double.  Integers, as per 22.2.3.1 in C++98, do not have an optional
'e' after them.  (Though of course you could *cast* a floating point value to
an integer.)  Given that, I hope you won't mind if I reopen the bug.


-- 

lpsmith at u dot washington dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2010-08-13 21:00 -------
You are of course wrong. Parsing something like "59e" as an integer type of
course succeeds and gives "59". Really, we have *tons* of testcases about that
in the testsuite. We know what we are doing ;)


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

------- Comment #7 from lpsmith at u dot washington dot edu  2010-08-13 21:14 -------
You're right!  Sorry; I apparently jumped to a conclusion while testing (but I
did test!)

I still disagree that an 'e' with no digit following can be reasonably
construed as part of an improperly-formatted float, and think it should instead
be considered not part of the float at all, since properly-formatted floats
have both the e and the digit.  I think you are erring on the side of assuming
an error when a valid interpretation exists.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2010-08-13 21:20 -------
I'm not erring. We changes this behavior on purpose, after having also checked
that *2* other, completely independent, implementations agree (ie, Dinkumware
and Roguewave).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

------- Comment #9 from lpsmith at u dot washington dot edu  2010-08-13 21:40 -------
Fair enough!  I still disagree, but I guess my task now is to get Dinkumware
and Roguewave to change their implementations, and come back.  I don't suppose
you'd be swayed by Microsoft?  I didn't think so ;-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280

[Bug libstdc++/45280] Stream parsing of digit-then-e (with no exponent) now fails

[lpsmith at u dot washington dot edu]

------- Comment #10 from lpsmith at u dot washington dot edu  2010-08-13 21:41 -------
Whoops, duh, dinkumware is ms.  Never mind, it was a dumb joke anyway.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280