Martin Sebor wrote:
Everton Araujo wrote:
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)

I have one other question for you about this patch, Everton:

Since we haven't heard from you I've committed the patch w/o
the bits in question:
  http://svn.apache.org/viewvc?rev=570897&view=rev

I'm also about to close the issue but if you think I've missed
something feel free to reopen it or follow up on this post.

Thanks again!
Martin



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);

The 0 is wrong (state_type need not be a scalar type), but
I assume you meant state_type (). Can you explain why this
correct and necessary?

Thanks
Martin

+            __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 <[EMAIL PROTECTED]>:
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.




Reply via email to