From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29645 invoked by alias); 11 Sep 2010 09:43:36 -0000 Received: (qmail 29607 invoked by uid 48); 11 Sep 2010 09:43:26 -0000 Date: Sat, 11 Sep 2010 09:43:00 -0000 Message-ID: <20100911094326.29606.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: "potswa at mac 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/msg01445.txt.bz2 ------- Comment #35 from potswa at mac dot com 2010-09-11 09:43 ------- (In reply to comment #34) > Run the full testsuite, and you will see. Lol, you're still looking at this too? I *just* got those pesky four testcases done. I wasn't manually putting the codecvt state into the fpos in the special case. I'll rerun the entire suite and post the patch here. > In general, if you simply do fseek(0, > cur) and then start writing, when eventually you have to flush you need the > actual logical position in the file - the last fseek(0, cur) - 'something' - > which is not available anywhere. No, if fseek(0,cur) is implemented to have no side effects, it has NO side effects. Nothing is lost. When the flush happens, it uses the logical position obtained at the last flush, just as if fseek(0,cur) never occurred. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628