You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Everton Araujo <ev...@gmail.com> on 2007/08/17 04:34:08 UTC
STDCXX-522 - v2
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.
Re: STDCXX-522 - v2
Posted by Everton Araujo <ev...@gmail.com>.
Thank you Martin and Andrew for helping me.
Below is
2007/8/17, Martin Sebor <se...@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.
> >>
> >
>
>
Re: STDCXX-522 - v2
Posted by Martin Sebor <se...@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.
>>
>
Re: STDCXX-522 - v2
Posted by Andrew Black <ab...@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.
>