Farid Zaripov
Mon, 23 Jul 2007 08:26:24 -0700
> -----Original Message-----
> From: Martin Sebor [EMAIL PROTECTED]
> Sent: Friday, July 20, 2007 2:04 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: STDCXX tests fails and reasons [MSVC]
>
> Farid Zaripov wrote:
> >> -----Original Message-----
> >> From: Martin Sebor [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 '@'?
Usually when rw_match() used for comparing the single characters, used rw_match (&c1, &c2, 1) form: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/strings/21.str ing.access.cpp?r1=552912&r2=552911&pathrev=552912 http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/strings/21.str ing.copy.cpp?r1=552912&r2=552911&pathrev=552912 Farid.