stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: STDCXX tests fails and reasons [MSVC]
Date Thu, 19 Jul 2007 23:03:34 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> 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 "a@0b"). We should not use rw_match() to compare single 
>>> characters.
>> I think something like rw_match("b", "a@0b") 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", "a@0b") should work, but 
> 
>   char c = 'b'; rw_match (&c, "a@0b", 1);
> or
>   char c = 'b'; rw_match ("a@0b", &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, "a@0b", 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 x@N sequences.
That's the problem, isn't it? That the function reads past
&c to see if there's an '@'?

Martin


Mime
View raw message