RE: svn commit: r416537 - /incubator/stdcxx/trunk/tests/src/char.cpp

[Anton Pevtsov <An...@moscow.vdiweb.com>]

Martin, I have a question about the change in char.cpp. It results in
the following:

1) The strings beginning with '\0' and requiring expand will not be
expanded.
2) The strings with '\0' at the end will be expanded incorrectly
(without last symbol).

Is this expected?


Thanks,
Anton Pevtsov


-----Original Message-----
From: sebor@apache.org [mailto:sebor@apache.org] 
Sent: Friday, June 23, 2006 05:15
To: stdcxx-commits@incubator.apache.org
Subject: svn commit: r416537 -
/incubator/stdcxx/trunk/tests/src/char.cpp


Author: sebor
Date: Thu Jun 22 18:14:52 2006
New Revision: 416537

URL: http://svn.apache.org/viewvc?rev=416537&view=rev
Log:
2006-06-22  Martin Sebor  <se...@roguewave.com>

	* char.cpp (_rw_expand): NUL-terminated expanded string.
	(rw_match): Avoided false positives when detecting whether
	to expand the first argument.

Modified:
    incubator/stdcxx/trunk/tests/src/char.cpp

Modified: incubator/stdcxx/trunk/tests/src/char.cpp
URL:
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/src/char.cpp?r
ev=416537&r1=416536&r2=416537&view=diff
========================================================================
======
--- incubator/stdcxx/trunk/tests/src/char.cpp (original)
+++ incubator/stdcxx/trunk/tests/src/char.cpp Thu Jun 22 18:14:52 2006
@@ -641,8 +641,10 @@
         pnext   = (char*)pnext + count * elemsize;
         buflen += count;
 
-        if (0 == src_len)
+        if (0 == src_len) {
+            memset (pnext, 0, elemsize);
             break;
+        }
     }
 
     if (dst_len)
@@ -690,10 +692,25 @@
     size_t s1_len = sizeof s1_buf;
 
     // see if the first string contains '@' and might need
-    // to be expanded  (see rw_expand() for details)
-    if (   _RWSTD_SIZE_MAX == len && strchr (s1, '@')
-        || _RWSTD_SIZE_MAX != len && memchr (s1, '@', len)) {
-        s1 = rw_expand (s1_buf, s1, len, &s1_len);
+    // to be expanded (see rw_expand() for details)
+    bool expand = false;
+
+    if (_RWSTD_SIZE_MAX == len) {
+        expand = 0 != strchr (s1, '@');
+    }
+    else {
+        for (const char *p = s1; *p; ++p) {
+            if (size_t (p - s1) == len)
+                break;
+            if ('@' == *p) {
+                expand = true;
+                break;
+            }
+        }
+    }
+
+    if (expand) {
+        s1  = rw_expand (s1_buf, s1, _RWSTD_SIZE_MAX, &s1_len);
         len = s1_len;
     }
 

Re: svn commit: r416537 - /incubator/stdcxx/trunk/tests/src/char.cpp

[Martin Sebor <se...@roguewave.com>]

Martin Sebor wrote:
> Anton Pevtsov wrote:
> 
>> Martin, I have a question about the change in char.cpp. It results in
>> the following:
>>
>> 1) The strings beginning with '\0' and requiring expand will not be
>> expanded.
> 
> 
> You mean something like "\0@3" or "\0a@3"?
> 
>> 2) The strings with '\0' at the end will be expanded incorrectly
>> (without last symbol).
>>
>> Is this expected?
> 
> 
> No, it's not. The test for the function seems to be exercising
> these cases and none of them fails. Can you show me an example
> where the function behaves unexpectedly?

FYI, I committed the change below to the 0.char.cpp test. It fixes
a bug in a call to memcmp() when testing the wchar_t overload of
rw_expand() and adds a few more test cases for the function. But
even with these changes I still don't see the problem you were
describing (or I'm not understanding you correctly).

http://svn.apache.org/viewvc?rev=416778&view=rev

Martin

Re: svn commit: r416537 - /incubator/stdcxx/trunk/tests/src/char.cpp

[Martin Sebor <se...@roguewave.com>]

Anton Pevtsov wrote:
> Martin, I have a question about the change in char.cpp. It results in
> the following:
> 
> 1) The strings beginning with '\0' and requiring expand will not be
> expanded.

You mean something like "\0@3" or "\0a@3"?

> 2) The strings with '\0' at the end will be expanded incorrectly
> (without last symbol).
> 
> Is this expected?

No, it's not. The test for the function seems to be exercising
these cases and none of them fails. Can you show me an example
where the function behaves unexpectedly?

FYI, I made the changes to prevent rw_match() errors in cases
like:

     rw_match ("abc", "abcdef", 6)

The function would call memchr(s1, '@', 6), which is wrong
because s1 is only 4 characters long (including the terminating
NUL).

Martin