[Bug libstdc++/42857] New: std::istream::ignore(std::streamsize n) calls unnecessary underflow

[Bug libstdc++/42857] New: std::istream::ignore(std::streamsize n) calls unnecessary underflow

[tommi at tntnet dot org]

When ignoring the number of bytes available in a streambuf using
std::istream::ignore, ignore calls underflow. This should not happen. I feel
the easiest way to reproduce it is to look at strace output when ignoring bytes
from ifstream:

#include <iostream>
#include <fstream>

int main(int argc, char* argv[])
{
  std::ifstream in(argv[0]);
  in.get(); // trigger filling of input buffer by calling underflow
  in.ignore(in.rdbuf()->in_avail());  // this triggers another underflow
}

The strace output shows, that 2 calls to read with 8191 bytes occures. When
ignoring one byte less and then another byte, only one read is done:

#include <iostream>
#include <fstream>

int main(int argc, char* argv[])
{
  std::ifstream in(argv[0]);
  in.get(); // trigger filling of input buffer
  in.ignore(in.rdbuf()->in_avail() - 1);
  in.ignore(1); // this does not trigger underflow
}


-- 
           Summary: std::istream::ignore(std::streamsize n) calls
                    unnecessary underflow
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tommi at tntnet dot org
GCC target triplet: i486-linux-gnu


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

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2010-01-27 21:09 -------
Putting aside the strange inconsistency of the second example, which could be
easily fixed, and probably should anyway (we have an overload corresponding to
n == 1 which calls sbumpc and should probably call snextc instead for a
consistent behavior), I think the issue boils down to a very old interpretation
issue in these sections of the standard, where it uses wording of the form "any
of the following occurs" (the same happens for get, getline, the issue isn't
limited to ignore) and it's not clear at all whether, when the target n is
reached, thus n characters are extracted, the second termination condition,
which involves checking for end-of-file, is still relevant or not, or, in
principle could even have been computed first, before checking the value of n. 

In short, I understand your request as a request of evaluating the conditions
exactly in the order written in the Standard, and as soon as one holds, the
following ones simply ignored. It's not what we have been doing, uniformly
(modulo the buglet above) across this area, but indeed makes sense. Note
however that a rather noticeable consequence of your interpretation is that
ignoring exactly to end-of-line would not set the eofbit anymore in the stream,
because we would not do getc on it. Now instead we uniformly set eofbit when
it's actually the case (and setting it could even throw, a very noticeable
behavior)

Thus, I believe that, besides the buglet above, we should give this issue much
more thought, likely it's even too late for 4.5.0, and I'd like to involve
Nathan in the discussion, I'm pretty sure I learned from him, some time ago,
about the tricky point of the "any of the following occurs"-type
specifications.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ncm at cantrip dot org


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

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2010-09-20 12:15 -------
I was having a second look to this issue, and noticed something more which I
missed the first time: the Standard, *only* in the case of getline(char_type*,
streamsize, char_type) explicitly says "These conditions are tested in the
order shown.". In my opinion that means that the get and ignore overloads using
the famous "any of the following occurs" can in principle check the conditions
in *any* implementation defined order and being conforming. Now, we have a case
here where we have an additional underflow because in our implementation we
uniformly insist on always checking whether end-of-file occurs in the sequence,
thus setting eofbit (besides the special case of ignore(), as already noticed)
in that case, like the above mentioned getline does, for example. I want to
understand how critical this additional underflow is, performance-wise, which,
as far as I can see normally can be triggered only by passing in_avail to
ignore, because otherwise, frankly, I find our consistent implementation
defined behavior across the various get, getline, ignore overloads pretty nice.


-- 


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