From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18492 invoked by alias); 13 Jul 2009 19:59:15 -0000 Received: (qmail 18470 invoked by uid 48); 13 Jul 2009 19:59:03 -0000 Date: Mon, 13 Jul 2009 19:59:00 -0000 Message-ID: <20090713195903.18469.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/40732] fstream get/put pointers have unexpected positions 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: 2009-07/txt/msg01052.txt.bz2 ------- Comment #3 from paolo dot carlini at oracle dot com 2009-07-13 19:59 ------- The pointers are in some sense independent, but in this exact technical sense: a seekg ends up calling the seekoff fstream virtual and therefore the mode becomes 'uncommitted', neither read mode neither write mode. Successive writes are therefore well defined and proceed exactly from the place where the last read took place. Alternately, you could achieve the same net effect by stopping reading when end of file is extracted: in C, and C++, this is a special case, which also leads to 'uncommitted' mode, thus the following writes are well defined - evidently in this case the user wants to append. But you can find many testcases about all the various behaviors in the testsuite. Since this is free software I also encourage you to browse the actual implementation: the last special case, for example, is very clear toward the end of basic_filebuf::underflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40732