Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 9:30 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: STDCXX tests fails and reasons [MSVC]
The problem is in that rw_match() used to compare single
characters.
There no problem in compare one character NUL-terminated
string (i.e.
"b" or "[EMAIL PROTECTED]"). We should not use rw_match() to compare single
characters.
I think something like rw_match("b", "[EMAIL PROTECTED]") should work,
just as long as we do the special processing on just one of
the two arguments (the second one in this case) and not both.
rw_match("b", "[EMAIL PROTECTED]") should work, but
char c = 'b'; rw_match (&c, "[EMAIL PROTECTED]", 1);
or
char c = 'b'; rw_match ("[EMAIL PROTECTED]", &c, 1);
or
char c1 = 'b', c2 = 'b'; rw_match (&c1, &c2, 1);
shouldn't (may cause undefined behavior i.e. when the memory byte right
after c or c1 or c2 contain '@').
What I was trying to say was that rw_match (&c, "[EMAIL PROTECTED]", 1)
will work even when (&c + 1) is an invalid address after
we've changed the function to treat the first argument as
an ordinary string without interpreting any [EMAIL PROTECTED] sequences.
That's the problem, isn't it? That the function reads past
&c to see if there's an '@'?
Martin
[jira] Assigned: (STDCXX-466) basic_string<>::rfind() throws length_error(), but should return npos
[ https://issues.apache.org/jira/browse/STDCXX-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-466: Assignee: Farid Zaripov > basic_string<>::rfind() throws length_error(), but should return npos > - > > Key: STDCXX-466 > URL: https://issues.apache.org/jira/browse/STDCXX-466 > Project: C++ Standard Library > Issue Type: Bug > Components: 21. Strings >Affects Versions: 4.2 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov > > The details are here: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: STDCXX tests fails and reasons [MSVC]
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 19, 2007 9:30 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: STDCXX tests fails and reasons [MSVC]
>
> > The problem is in that rw_match() used to compare single
> characters.
> > There no problem in compare one character NUL-terminated
> string (i.e.
> > "b" or "[EMAIL PROTECTED]"). We should not use rw_match() to compare single
> > characters.
>
> I think something like rw_match("b", "[EMAIL PROTECTED]") should work,
> just as long as we do the special processing on just one of
> the two arguments (the second one in this case) and not both.
rw_match("b", "[EMAIL PROTECTED]") should work, but
char c = 'b'; rw_match (&c, "[EMAIL PROTECTED]", 1);
or
char c = 'b'; rw_match ("[EMAIL PROTECTED]", &c, 1);
or
char c1 = 'b', c2 = 'b'; rw_match (&c1, &c2, 1);
shouldn't (may cause undefined behavior i.e. when the memory byte right
after c or c1 or c2 contain '@').
Farid.
Re: std::deque<>::_C_insert_1() declared but not defined
Farid Zaripov wrote: In include/deque header file the deque<>::_C_insert_1() method is declared, but not defined. include/deque, line 684: - // implements a single-element insert void _C_insert_1 (const iterator&, const_reference); - This method is never used, so there no problems, but MSVC issues warning: warning C4661: 'void std::deque<_>::_C_insert_1(...)' : no suitable definition provided for explicit template instantiation request I think I meant to provide it as an optimization, the same way _C_insert_1() is provided in vector but never finished it. We can probably take it out for now but we should come back to it in the future. It might be a useful optimization, and our deque is in need of performance improvement. Martin
std::deque<>::_C_insert_1() declared but not defined
In include/deque header file the deque<>::_C_insert_1() method is declared, but not defined. include/deque, line 684: - // implements a single-element insert void _C_insert_1 (const iterator&, const_reference); - This method is never used, so there no problems, but MSVC issues warning: warning C4661: 'void std::deque<_>::_C_insert_1(...)' : no suitable definition provided for explicit template instantiation request Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, July 02, 2007 8:23 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: STDCXX tests fails and reasons [MSVC]
Jira for the "bug in rw_match(&char, &char, 1)."
But is that really a bug in rw_match()? It looks to me
more like a design limitation than a bug. In the case of the
wchar_t* and UserChar* overloads of rw_match() there should
be a simple solution: make sure the first (char*) argument
has enough elements (it should be easy to guarantee that
since the argument is the hardcoded string we match against).
And changing the char* overload to behave the same as the
other two, i.e., to only do the expansion on the first
argument and not on the second should fix that case, no?
The problem is in that rw_match() used to compare single characters.
There no problem in compare one character NUL-terminated string
(i.e. "b" or "[EMAIL PROTECTED]"). We should not use rw_match() to compare
single characters.
I think something like rw_match("b", "[EMAIL PROTECTED]") should work, just
as long as we do the special processing on just one of the two
arguments (the second one in this case) and not both. The
problem, as I understand it, is that we process both strings
in the (char*, char*) case.
Martin
RE: [patch] STDCXX-170
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 18, 2007 3:58 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [patch] STDCXX-170
>
> Farid Zaripov wrote:
> > Here is proposed patch to fix STDCXX-170 issue:
> >
> > ChangeLog:
> > * string.cc (replace): Copy data to temporary string object
> > if data is a part of the internal string buffer.
> >
> > Index: string.cc
> > ===
> > --- string.cc (revision 556830)
> > +++ string.cc (working copy)
> > @@ -516,6 +516,15 @@
> > _RWSTD_ASSERT_RANGE (__first1, __last1);
> > _RWSTD_ASSERT_RANGE (__first2, __last2);
> >
> > +if ( !(__first2 == __last2)
> > +&& __s._C_data <= &*__first2
> > +&& __s._C_data + __s.size () > &*__first2) {
>
> I don't think this exression is guaranteed to be well-formed.
> InputIterator's operator* can return an rvalue (rather than
> a const reference) which would break operator &. The test
> case below should compile. Does it with your change?
You're right. This test case fails to compile with my patch.
I looked into STLport sources to see how it deals with that problem.
The STLport performs checking only if InputIter is
basic_string::iterator
or basic_string::const_iterator:
template
void _M_insert_dispatch(iterator __p, _InputIter __first, _InputIter
__last,
const __false_type& /*Integral*/) {
_STLP_FIX_LITERAL_BUG(__p)
/*
* Within the basic_string implementation we are only going to check
for
* self referencing if iterators are string iterators or _CharT
pointers.
* A user could encapsulate those iterator within their own iterator
interface
* and in this case lead to a bad behavior, this is a known
limitation.
*/
typedef typename _AreSameUnCVTypes<_InputIter, iterator>::_Ret
_IsIterator;
typedef typename _AreSameUnCVTypes<_InputIter, const_iterator>::_Ret
_IsConstIterator;
typedef typename _Lor2<_IsIterator, _IsConstIterator>::_Ret
_CheckInside;
_M_insert_aux(__p, __first, __last, _CheckInside());
}
Farid.
Re: MyStreambuf class is incomplete
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, July 18, 2007 7:16 AM To: stdcxx-dev@incubator.apache.org Subject: Re: MyStreambuf class is incomplete Farid Zaripov wrote: The throw_when_ mebmer of the MyStreambuf class (rw_streambuf.h line 183) is not initialized at the moment in class ctor's (only zero'ed), but used in MyStreambuf::test() (lines 472, 483). I suppose that this class designed to initialize throw_when_ within test functions. But for now the all iostream tests doesn't do it. Maybe we just remove this mebmer at all? The patch is ready :) I'm not dead set against removing it but if it ain't broke...? Is it actually causing problems or are you just cleaning things up? It causing problems because the tests are uses fail_when parameter to set when MyStreambuf should to throw, but MyStreambuf throws only if throw_when_ [inx] == callno. So we should to apply my patch (remove throw_when_ and throw when fail_when_ == callno, or modify all tests to set throw_when_[] array. I think I remember now. IIRC, the intent behind the throw_when_ array is to make it possible to induce exceptions only from specific functions without accidentally making some other function called from the first throw instead. The purpose of the fail_when member is to make the tested function fail after that many calls. So I think we need to keep the array and fix the tests, otherwise we might cause failures because of exceptions being thrown by the wrong functions. Don't you think? Martin
RE: Intel C++ build issues on Windows
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, July 18, 2007 7:47 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: Intel C++ build issues on Windows > > Another option is to rig one of the library headers (e.g., > _config.h) to optionally #include some header that we could > then "insert" by defining the right magic macro. Like this: > >// _defs.h >#ifdef _RWSTD_INCLUDE_HEADER ># include _RWSTD_INCLUDE_HEADER >#endif > > then we'de compile our examples with the following option on > the command line: > -D_RWSTD_INCLUDE_HEADER=examples/include/include.h Personally, I prefer this option. Farid.
RE: MyStreambuf class is incomplete
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, July 18, 2007 7:16 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: MyStreambuf class is incomplete > > Farid Zaripov wrote: > > The throw_when_ mebmer of the MyStreambuf class > (rw_streambuf.h line > > 183) is > > not initialized at the moment in class ctor's (only > zero'ed), but used > > in > > MyStreambuf::test() (lines 472, 483). I suppose that this class > > designed to initialize throw_when_ within test functions. > But for now > > the all iostream tests doesn't do it. > > Maybe we just remove this mebmer at all? The patch is ready :) > > I'm not dead set against removing it but if it ain't broke...? > Is it actually causing problems or are you just cleaning things up? It causing problems because the tests are uses fail_when parameter to set when MyStreambuf should to throw, but MyStreambuf throws only if throw_when_ [inx] == callno. So we should to apply my patch (remove throw_when_ and throw when fail_when_ == callno, or modify all tests to set throw_when_[] array. Farid.
Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, July 18, 2007 7:12 AM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp No, because of _config-msvcrt.h, line 151: // operator new and delete is not reliably replaceable across // shared library boundaries, which includes the shared library // version of the language support library #define _RWSTD_NO_REPLACEABLE_NEW_DELETE Shall we install SIGSEGV signal handler only if _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is #defined ? Right. Then the test for the replacement operator new should be guarded by the macro, shouldn't it? I think it should, but then the all 0.new.cpp test should be guarded by the macro, because of all test cases in this test are excercising the replacement new/delete operators: True. If there's no way to reliably replace operators new and delete on Windows that's what we'll have to do. I thought I heard that it was possible with some MSVC-specific hackery. If you can find some docs on how to it that would great. If not, let's just guard the test (as we do the uses of the replacement operator new machinery) and be done with it. Martin
RE: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, July 18, 2007 7:12 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r553587 - > /incubator/stdcxx/trunk/tests/self/0.new.cpp > > > No, because of _config-msvcrt.h, line 151: > > > >// operator new and delete is not reliably replaceable across > >// shared library boundaries, which includes the shared library > >// version of the language support library #define > > _RWSTD_NO_REPLACEABLE_NEW_DELETE > > > > Shall we install SIGSEGV signal handler only if > > _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is #defined ? > > Right. Then the test for the replacement operator new should > be guarded by the macro, shouldn't it? I think it should, but then the all 0.new.cpp test should be guarded by the macro, because of all test cases in this test are excercising the replacement new/delete operators: /*** * * 0.new.cpp - test exercising replacement operator new and delete Farid.
