incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Everton Araujo" <everton.ba...@gmail.com>
Subject [PATCH] STDCXX-522
Date Fri, 17 Aug 2007 22:49:51 GMT
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 <ablack@roguewave.com>:
>
> 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<class _CharT, class _Traits>
> > _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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message