stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Everton Araujo" <everton.ba...@gmail.com>
Subject Re: STDCXX-522 - v2
Date Fri, 17 Aug 2007 22:41:56 GMT
Thank you Martin and Andrew for helping me.

Below is


2007/8/17, Martin Sebor <sebor@roguewave.com>:
>
> To give you some concrete examples of what Andrew is talking about,
> here are few patches in the expected format that were submitted to
> the list for review:
>
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04232.html
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04029.html
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03993.html
>
> The process of submitting patches and their format is formally
> described on this page (see Submitting Patches and Patch Format):
> http://incubator.apache.org/stdcxx/bugs.html
>
> If you have any questions or need help with any of it don't hesitate
> to ask!
>
> Matin
>
> Andrew Black wrote:
> > 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