From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10973 invoked by alias); 10 Sep 2010 10:55:13 -0000 Received: (qmail 10873 invoked by uid 48); 10 Sep 2010 10:55:01 -0000 Date: Fri, 10 Sep 2010 10:55:00 -0000 Message-ID: <20100910105501.10872.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer 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-09/txt/msg01321.txt.bz2 ------- Comment #2 from paolo dot carlini at oracle dot com 2010-09-10 10:55 ------- _M_terminate_output, correctly, does nothing in this case, cannot be the problem, and there is nothing wrong wrt the standard mandated behavior. The "problem" is that in our implementation, similarly to traditional C stdio impls, reading and writing are completely separate operations, and the user switches between the two with seeks, essentially. Any seek puts back the internal status to "uncommitted" (_M_reading = false, _M_writing = false) and afterwards the user can start *either* reading or writing, irrespective of the previous history, and the seek logic doesn't know what will actually happen in the future, of course. The user should not perform redundant seeks, because they have a cost, they do something more than just "seeking". On the other hand, a series of read or write operations has maximum performance, we don't think we could possibly do better. Thus, I'm open to ideas, but I don't think that within the current design one can change / improve much. Note that the patch you linked is exactly the one implementing the above semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628