From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12451 invoked by alias); 27 Jan 2010 21:10:09 -0000 Received: (qmail 12317 invoked by uid 48); 27 Jan 2010 21:09:53 -0000 Date: Wed, 27 Jan 2010 21:10:00 -0000 Message-ID: <20100127210953.12316.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "paolo dot carlini at oracle dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg03149.txt.bz2 ------- 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