RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[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 [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 '@'? 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=552912r2=552911pathrev=552912 http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/strings/21.str ing.copy.cpp?r1=552912r2=552911pathrev=552912 Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[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 [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 '@'? Usually when rw_match() used for comparing the single characters, used rw_match (c1, c2, 1) form: But that's the wrong way to do it. The right (and easier) way to compare individual characters of the same type is to use UserTraits::eq(). rw_match() can be used as well but one of the arguments (and for char currently both, until we change it) must be a valid pattern string. Martin http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/strings/21.str ing.access.cpp?r1=552912r2=552911pathrev=552912 http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/strings/21.str ing.copy.cpp?r1=552912r2=552911pathrev=552912 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: 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: 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
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 6:51 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. Exactly right. So let's fix it :) Done: http://svn.apache.org/viewvc?view=revrev=553924 Farid.
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Is this valid operation (I mean to pass the internal basic_stringbuf buffer in basic_stringbuf::sputn())? Btw the Dinkumware STL has the similar problem. There's no requirement that makes it invalid but it's not something we'll see every day :) Let me look into it a bit to better understand what's going on there. Fixed thus: http://svn.apache.org/viewvc?view=revrev=553931 Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Is this valid operation (I mean to pass the internal basic_stringbuf buffer in basic_stringbuf::sputn())? Btw the Dinkumware STL has the similar problem. There's no requirement that makes it invalid but it's not something we'll see every day :) Let me look into it a bit to better understand what's going on there. Fixed thus: http://svn.apache.org/viewvc?view=revrev=553931 Okay, thanks. The type of off should be ptrdiff_t (spelled _RWSTD_PTRDIFF_T, of course), and the name needs to be in the private namespace (i.e., __off). Martin
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 6:51 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. Exactly right. So let's fix it :) Done: http://svn.apache.org/viewvc?view=revrev=553924 Looks good! Thanks Martin
RE: STDCXX tests fails and reasons [MSVC]
-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. Farid.
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Another problem in that test is difference between char_traitschar::eof() == int(-1) and char_traitswchar_t::eof() == int (65536). char_traitswchar_t::eof() should equal WEOF. Is WEOF equal to 65536 on Windows? Yes. Below is a definition of the WEOF in wctype.h (MSVC 8): #define WEOF (wint_t)(0x) The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. Exactly right. The basic_stringbuf::pbackfail() test (line 637) expected EOF == -1 and issues rw_error() diagnostic on whar_t tests. Is this still 27.stringbuf.virtuals.cpp? I don't see any rw_error() in there. Line 637 is the first line with failed test (EOF expected, WEOF got). //+- initial sequence (if any) //| +-- open mode //| | + gbump (gptr offset) //| | | + pbackfail argument //| | | | + expected return value //| | | | |+--- number of putback positions //| | | | || + number of read positions //| | | | || | +- number of write positions //| | | | || | | //V V V V VV V V TEST (0, 0,0, 'c', EOF, 0, 0, -1); Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Another problem in that test is difference between char_traitschar::eof() == int(-1) and char_traitswchar_t::eof() == int (65536). char_traitswchar_t::eof() should equal WEOF. Is WEOF equal to 65536 on Windows? Yes. Below is a definition of the WEOF in wctype.h (MSVC 8): #define WEOF (wint_t)(0x) The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. Exactly right. So let's fix it :) I didn't look very carefully (it's been over a year since I wrote it) but I wonder if we could fix it by translating the EOF used in test cases to char_traitscharT::eof() in the test function. Martin The basic_stringbuf::pbackfail() test (line 637) expected EOF == -1 and issues rw_error() diagnostic on whar_t tests. Is this still 27.stringbuf.virtuals.cpp? I don't see any rw_error() in there. Line 637 is the first line with failed test (EOF expected, WEOF got). //+- initial sequence (if any) //| +-- open mode //| | + gbump (gptr offset) //| | | + pbackfail argument //| | | | + expected return value //| | | | |+--- number of putback positions //| | | | || + number of read positions //| | | | || | +- number of write positions //| | | | || | | //V V V V VV V V TEST (0, 0,0, 'c', EOF, 0, 0, -1); Farid.
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:34 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Farid Zaripov wrote: The list of the fails and reasons (which I've checked at the moment) is here: http://people.apache.org/~faridz/test_status.html I vaguely recall discussing the problem but I don't see an issue in Jira for the bug in rw_match(char, char, 1). Is this it? http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/ms g01569.html No. the last message is here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg01893.htm l Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:34 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Farid Zaripov wrote: The list of the fails and reasons (which I've checked at the moment) is here: http://people.apache.org/~faridz/test_status.html I vaguely recall discussing the problem but I don't see an issue in Jira for the bug in rw_match(char, char, 1). Is this it? http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/ms g01569.html No. the last message is here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg01893.htm l I see. 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? Martin
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: The list of the fails and reasons (which I've checked at the moment) is here: http://people.apache.org/~faridz/test_status.html Thanks, this is very helpful! I have question on test 27.stringbuf.virtuals. There in basic_stringbuf::xsputn() the first parameter passed pointer to the internal basic_stringbuf buffer (basic_stringbuf::pbase()). And if size of the internal buffer is not enough to receive requested number of characters, reallocation occurred and then the previous buffer (deallocated at this moment) used as source characters. Is this valid operation (I mean to pass the internal basic_stringbuf buffer in basic_stringbuf::sputn())? Btw the Dinkumware STL has the similar problem. There's no requirement that makes it invalid but it's not something we'll see every day :) Let me look into it a bit to better understand what's going on there. Another problem in that test is difference between char_traitschar::eof() == int(-1) and char_traitswchar_t::eof() == int (65536). char_traitswchar_t::eof() should equal WEOF. Is WEOF equal to 65536 on Windows? The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. The basic_stringbuf::pbackfail() test (line 637) expected EOF == -1 and issues rw_error() diagnostic on whar_t tests. Is this still 27.stringbuf.virtuals.cpp? I don't see any rw_error() in there. Martin
