stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PATCH] STDCXX-522
Date Fri, 24 Aug 2007 22:58:55 GMT
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:

> 
> 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 <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
View raw message