Martin Sebor wrote: > But before committing the rest we need to first settle the issue of rw_expand().
Martin, in my previous mail I didn't mention that the problem occur when rw_expand is called from the rw_match function. Sorry about that. The test which illustrates the problem is here: http://people.apache.org/~antonp/stdcxx06262006/rwmatch_rwexpand_test.cp p Martin Sebor wrote: [...] > I plan to write up an issue against the standard and propose the consistent behavior that makes sense to me but in the meantime we need to decide whether to pedantically follow the current > requirements (and make changes where we don't), whether to implement the proposed behavior, or whether to leave things alone. Any suggestions? The possible fix of the STDCXX-206 and STDCXX-205 is here http://people.apache.org/~antonp/stdcxx06262006/lib/ It required changes in several places: For fix issue 205 call strm.width(0) should be called after check if (bool(sentry)) { ... strm.width(0); } For fix issue 206 call strm.width(0) should be called before call strm.setstate(newstate); The function template<class _CharT, class _Traits, class _Allocator> inline basic_ostream<_CharT, _Traits>& operator<< (basic_ostream<_CharT, _Traits> & __strm, const basic_string<_CharT, _Traits, _Allocator> &__str) all work performs using another function _EXPORT template<class _CharT, class _Traits, class _StringT> _STD::basic_ostream<_CharT, _Traits>& __rw_insert (_STD::basic_ostream<_CharT, _Traits> &__strm, const _StringT *__s, _RWSTD_STREAMSIZE __len, _RWSTD_STREAMSIZE __width) And after a call __rw_insert it's call strm.width(0); So for fix the issues need: 1. copy code from __rw_insert to operator<< and then modify according to issue requirements Or 2. move call strm.width(0) to inside __rw_insert and add additional information on necessity of a call of strm.width(0) (because __rw_insert used in many other places like operater<<(istream&, char), ...) I implemented variant 2: __rw_insert now have additional argument bool __zerowidth, by default is false and doesn't change behaviour of function in those places where it is called without explicit definition of the value __zerowidth. _EXPORT template<class _CharT, class _Traits, class _StringT> _STD::basic_ostream<_CharT, _Traits>& __rw_insert (_STD::basic_ostream<_CharT, _Traits> &__strm, const _StringT *__s, _RWSTD_STREAMSIZE __len, _RWSTD_STREAMSIZE __width, bool __zerowidth/* = false*/) then I put next lines right after of characters insertion code if (__zerowidth) __strm.width (0); then I put next lines right after of characters insertion code and added check that the I/O operation was successful. if (__zerowidth && __err == _STD::ios_base::goodbit) __strm.width (0); And at last I changed // 21.3.7.9, p3 - defined here, declared inline in <string> template<class _CharT, class _Traits, class _Allocator> inline basic_ostream<_CharT, _Traits>& operator<< (basic_ostream<_CharT, _Traits> & __strm, const basic_string<_CharT, _Traits, _Allocator> &__str) { _RW::__rw_insert (__strm, __str.data (), __str.length (), __strm.width ()).width (0); Return __strm; } To the // 21.3.7.9, p3 - defined here, declared inline in <string> template<class _CharT, class _Traits, class _Allocator> inline basic_ostream<_CharT, _Traits>& operator<< (basic_ostream<_CharT, _Traits> & __strm, const basic_string<_CharT, _Traits, _Allocator> &__str) { return _RW::__rw_insert (__strm, __str.data (), __str.length (), __strm.width (), true); } The same changes may be needed in other overloads of the operator<< for streams. What do you think about this? New test version updated according the fix above is here: http://people.apache.org/~antonp/stdcxx06262006/ Thanks, Anton Pevtsov -----Original Message----- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Saturday, June 24, 2006 00:09 To: [email protected] Subject: Re: test for lib.string.io Anton Pevtsov wrote: > The first version of the test with the required changes to 21.string.* > and rw_streambuf.h is here: > http://people.apache.org/~antonp/stdcxx06232006/ Wow, this looks very good! It will need more comments but we can add those later. I suspect I might be in a good position to suggest some since I'm not familiar with the code and I'm trying to understand how it works :) > Also there is a small change to char.cpp to allowing the strings > ending with '\0' expanding. I see it but as I mentioned in my previous replies I don't think the len argument is correct there. I'll need to better understand where the problem is (as I said, a test case would help). > > The test generates asserts due to STDCXX-206 and problem with > ios_base::badbit / failbit. I have been thinking about STDCXX-206 and the general issue of when width(0) should be called. My feeling is that width should only be reset if the I/O operation completes successfully. I.e., when there is no indication of an error and when no exception is thrown. This is slightly different from what the standard requires but I think it makes more sense than the current (inconsistent) requirements where width(0) is supposed to be unconditionally called in some cases (before any I/O) and in others only when there hasn't been an exception (but regardless of whether the I/O operation was successful or not). I plan to write up an issue against the standard and propose the consistent behavior that makes sense to me but in the meantime we need to decide whether to pedantically follow the current requirements (and make changes where we don't), whether to implement the proposed behavior, or whether to leave things alone. Any suggestions? > Also there is a question about exception safety: > > If exceptions mask == ios_base::goodbit then operator>>, operator << > and getline hides all exceptions thrown inside function. The > Dinkumware does the same, but STLPort doesn't. Is this correct? The general policy for how to deal with exceptions in iostreams (outlined briefly in 27.6.1.1, p4) is that all exceptions should be caught and swallowed unless badbit is set in exceptions(). This policy is reinforced in the common requirements on formatted and unformatted I/O functions (27.6.1.2.1, 27.6.1.2.3, 27.6.2.5.1, and 27.6.2.6). Since both operator>> and getline() are explicitly required to behave as formatted and unformatted input functions, respectively, they must follow the policy (i.e., STLport fails to conform). The case of operator<< for string is less clear since it doesn't contain the same requirement, but it seems pretty clear to me that it should (I can't think of any reason why not and so far no one on the committee has come up with one either). > > > During the test implementation I found that there is a problem with > test linking on Windows, 11d and 15d configurations: "unresolved > external symbol "public: static struct __rw::__rw_mutex > __rw::__rw_synchronized::_C_mutex" > I investigate the problem and found that this member of > __rw_synchronized structure is not marked as _RWSTD_EXPORT. The > possible fix to this issue is here (differeces to files > include/rw/_mutex.h and src/exception.cpp): > http://people.apache.org/~antonp/stdcxx06232006/lib/ > What do you think about this? The fix looks good, please go ahead and commit it. But before committing the rest we need to first settle the issue of rw_expand(). Martin
