Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 25048 invoked from network); 17 Aug 2007 22:50:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Aug 2007 22:50:15 -0000 Received: (qmail 70495 invoked by uid 500); 17 Aug 2007 22:50:13 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 70486 invoked by uid 500); 17 Aug 2007 22:50:13 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 70475 invoked by uid 99); 17 Aug 2007 22:50:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 15:50:13 -0700 X-ASF-Spam-Status: No, hits=3.8 required=10.0 tests=HTML_MESSAGE,SPF_PASS,SUBJ_ALL_CAPS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of everton.basso@gmail.com designates 209.85.146.178 as permitted sender) Received: from [209.85.146.178] (HELO wa-out-1112.google.com) (209.85.146.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 22:50:12 +0000 Received: by wa-out-1112.google.com with SMTP id j5so405725wah for ; Fri, 17 Aug 2007 15:49:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=iGjNR9EZXHJQP0ZqaQru7i7/ummNMwVGjYUuin0lJDJVfXMCyzA1ThiFVOAmjR+xdWKCMcbjruQMsKjtSHtABaLt+H295ZrklUPmLSbR2H69QHj8P9T6/r1v/kHJ+d81i960CpoIEYevW3e6QacJKiZz0QCx8wxPRWto1lfXkBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=BnyG52i27zyncYdGLUV6dJR9eqRunJYi+6ZuSsUPGQtQ6KrHmbRrnCfWvmPwAYUSTTaOHfhpCSi3PSKRjIJyazq+OatjcFwP+fDRFoBB+iKIM765CjHaT8TBhhE+bqfhSzQ0bVh2qoLPmTqiOINZd3qrJc4G3haSpyLS6TUytKU= Received: by 10.114.161.11 with SMTP id j11mr345452wae.1187390991759; Fri, 17 Aug 2007 15:49:51 -0700 (PDT) Received: by 10.114.112.8 with HTTP; Fri, 17 Aug 2007 15:49:51 -0700 (PDT) Message-ID: Date: Fri, 17 Aug 2007 19:49:51 -0300 From: "Everton Araujo" To: stdcxx-dev@incubator.apache.org Subject: [PATCH] STDCXX-522 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_84942_13566498.1187390991724" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_84942_13566498.1187390991724 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank you Martin and Andrew for helping me. Below is the patch for STDCXX-522 (std::filebuf::overflow(EOF) writes EOF to file in unbuffered mode) Index: include/fstream.cc =================================================================== --- include/fstream.cc (revision 566470) +++ include/fstream.cc (working copy) @@ -351,8 +351,15 @@ _RWSTD_STREAMSIZE __nchars; if (__unbuf) { + if(this->_C_is_eof(__c)){ + _C_cur_pos.state (0); + __buf = 0; + __nchars = 0; + } + else{ __buf = &__c_to_char; __nchars = 1; + } } else { // call xsputn() with a special value to have it flush @@ -364,7 +371,7 @@ // typedef helps HP aCC 3.27 typedef basic_filebuf _FileBuf; - if (__nchars != _FileBuf::xsputn (__buf, __nchars)) + if (__nchars && __nchars != _FileBuf::xsputn (__buf, __nchars)) return traits_type::eof (); // error while writing } @@ -424,7 +431,7 @@ typedef basic_filebuf _FileBuf; // return -1 on error to flush the controlled sequence - if (__nwrite != _FileBuf::xsputn (__special, __nwrite)) + if (__nwrite && __nwrite != _FileBuf::xsputn (__special, __nwrite)) return -1; } Everton. 2007/8/17, Andrew Black : > > Greetings Everton. > > Your assistance is appreciated, but it is difficult to use (or > understand) your proposed changes without a context for the changes. > One piece of context we need to know is what sources you are making your > changes against - are you using the 4.1.3 release code, the 4.2.0 > pre-release subversion branch, or subversion trunk? While it is > possible to work with changes against all of the listed sources, changes > against subversion trunk are the most usable, as they are the simplest > to commit. > > If you wish to propose a change, the most usable format to share the > proposed change is in the form of a diff which is usable by the patch > utility. I, and a number of the other developers, have HTML rendering > turned off by default in our mail clients, so HTML formatted changes, > such as the one you provided, are very difficult to use. > > One of the reasons changes against subversion trunk are preferred is > because the subversion client is able to produce the diff files which > the patch utility can use. If you use the subversion command line > client, you can run the 'svn diff' command in the root directory of your > subversion checkout and redirecting the output to a file. If you use > the TortoiseSVN client, one of the menu options in the explorer > integration is 'Create patch...'. If this command is run against the > root directory of you subversion checkout, it will also produce a usable > patch in a file. In either case, the generated file can be embedded in > or attached to an email. If you use outlook, use a '.txt' suffix for > the patch so the mailing list doesn't strip it. > > Hopefully this information will make it easier to participate. > > --Andrew Black > > Everton Araujo wrote: > > Hi, > > > > Sorry, I was wrong about the fix of issue STDCXX-522 because it worked > for > > issue test code, but I've forgot to run test 27 and we I ran that ... > > oooops! 75% assertations :-( > > I went get more coffee and restart debugging, and with the following > changes > > in fstream, test on both codes (issue and 27) was successfully. > > > > Following is the overflow code changed (diffs are bold): > > > > template > > _TYPENAME basic_filebuf<_CharT, _Traits>::int_type > > basic_filebuf<_CharT, _Traits>:: > > overflow (int_type __c /* = eof () */) > > { > > _RWSTD_ASSERT (this->_C_is_valid ()); > > > > if (!this->_C_is_out () || !is_open ()) > > return traits_type::eof (); > > > > this->setg (0, 0, 0); // invalidate the get area > > > > const bool __unbuf = this->_C_is_unbuffered (); > > > > const char_type __c_to_char = traits_type::to_char_type (__c); > > > > if (this->pptr () == 0 && !__unbuf) { > > // put area not valid yet - just need to initialize it > > this->setp (this->_C_buffer, this->_C_buf_end ()); > > } > > else if ( this->pptr () == this->epptr () > > || this->_C_is_eof (__c) > > || __unbuf) { > > > > const char_type* __buf; > > _RWSTD_STREAMSIZE __nchars; > > > > if (__unbuf) { > > if(this->_C_is_eof(__c)){ > > _C_cur_pos.state (0); > > __buf = 0; > > __nchars = 0; > > } > > else{ > > __buf = &__c_to_char; > > __nchars = 1; > > } > > } > > else { > > // call xsputn() with a special value to have it flush > > // the controlled sequence to the file > > __buf = _RWSTD_REINTERPRET_CAST (char_type*, this); > > __nchars = this->pptr () - this->pbase (); > > } > > > > // typedef helps HP aCC 3.27 > > typedef basic_filebuf _FileBuf; > > > > if (__nchars && __nchars != _FileBuf::xsputn (__buf, __nchars)) > > return traits_type::eof (); // error while writing > > } > > > > // now that there's room in the buffer, call sputc() recursively > > // to actually place the character in the buffer (unless we're > > // in unbuffered mode because we just wrote it out) > > if (!this->_C_is_eof (__c) && !__unbuf) > > this->sputc (__c_to_char); > > > > this->_C_out_last (true); // needed by close () > > > > return traits_type::not_eof (__c); > > } > > > > Hope it helps. > > > > Everton. > > > ------=_Part_84942_13566498.1187390991724--