stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <abl...@roguewave.com>
Subject Re: STDCXX-522 - v2
Date Fri, 17 Aug 2007 15:15:27 GMT
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