stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Pevtsov <ant...@moscow.vdiweb.com>
Subject Re: Re: Re: test for 21.strings.capacity
Date Tue, 07 Mar 2006 16:36:40 GMT
The attached file contains the updated according to your notes version
of the test for 21.string.capacity.

Martin Sebor wrote:

> <>>Yes. That's the expected result. In general, the extended 
> formatting>directives (such as %{#*S}) format their arguments so that 
> they are human readable even when the arguments contain non-printable 
> characters.

Here I meant the following. Suppose my
basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> >
contains the string "abc". And when I printed it
out in the --trace mode using the %{#*S} directive I have got "a\0b", but
"abc" (or "a\0b\0c\0" if each byte is printed) was expected.
Is this correct?

Thanks,
Anton Pevtsov

> <>
>
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, March 07, 2006 02:14
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: test for 21.strings.capacity
>
>
> Anton Pevtsov wrote:

>> The attached file contains the updated version of the test for 
>> 21.string.capacity. I modified the code and pass the tested string 
>> length to the widen function and basic_string ctor to avoid the bug 
>> with strings containing embedded NULs.
>  
>

Okay. There still are a small number of improvements that I think would
make the test better. For one, it would be helpful to line up the
arguments to the TEST macro to make them easier to read. Also, it would
make the test for each member function more readable if you added arrows
pointing to each argument and documenting what each stands for (as is
already done in test_reserve).

I'm also not sure I understand the purpose of widening "a" when the str
argument is 0 in test_string_capacity. It seems that widen should be
called with the 0 pointer in this case (widen handles NULL pointers just
fine).

Finally, there is no difference between invoking the test function like
this

     TEST ("Test\0string", 11);

or like this:

     TEST ("Test\000string", 11);

Either way the effect is identical since \0 and \000 both represent the
NUL character. Instead I would exercise sequences of consecutive NULs
such as "\0", "\0\0", and "\0\0\0" and similar sequences but with
non-NULs thrown in, e.g., "\0a\0", "\0ab\0", etc.



>> But I suspect a bug in the rw_assert formatting output for {#*S}. The 
>> wchar string "abc" is displayed as "a\0b" (maybe the function dumps 
>> each byte, not symbol here).
>  
>

Yes. That's the expected result. In general, the extended formatting
directives (such as %{#*S}) format their arguments so that they are
human readable even when the arguments contain non-printable characters.
Here's an example:

     $ cat t.cpp && ./t
     #include <string>
     #include <rw_printf.h>

     int main ()
     {
         const std::string s ("abc\0def", 7);
         const std::wstring ws (L"abc\0def", 7);

         rw_printf ("%{#1S}\n", &s);
         rw_printf ("%{#*S}\n", sizeof (wchar_t), &ws);
     }

     "abc\0def"
     L"abc\0def"


>> 
>> Btw., maybe it would be useful to move the widen function to rw_char 
>> header (or some another place in the test driver).
>  
>

Definitely. I suspect three overloads of rw_widen() will actually be
useful (and already are being used in various forms throughout the test
suite):

   char*     rw_widen (char*,     const char*, size_t);
   wchar_t*  rw_widen (wchar_t*,  const char*, size_t);
   UserChar* rw_widen (UserChar*, const char*, size_t);

where the first is equivalent to memcpy().

Martin


Mime
View raw message