You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Anton Pevtsov <an...@moscow.vdiweb.com> on 2006/03/20 17:07:10 UTC

test for 21.string.copy

The attached file contains the test for lib.string.copy.

With best wishes,
Anton Pevtsov


Re: test for 21.string.copy

Posted by Martin Sebor <se...@roguewave.com>.
Anton Pevtsov wrote:
> The attached file contains the test for lib.string.copy.

I made a few changes -- see the attached diff.

exp_exceptions[] was missing element[2] (dereferenced later in the
test). I added it.

I introduced the LSTR and LLEN convenience macros to make it easier
to refer to long_string and long_string_len.

I made TestCase::str and TestCase::res const to avoid having to cast
away the constness of string literals used to define the array and
silence gcc warnings about the same.

I made the MemFun pointer argument const since pointed-to object is
not modified by any of the functions. I replaced the s_empty object
with a constant eos character for simplicity. I also added const
wherever possible. Making all objects that aren't modified makes
code easier to understand. Let's use const wherever possible.

I added a few assertions to assert test preconditions. Please use
the RW_ASSERT() to assert any assumptions made in all tests :)

I initialized the destination buffer to all garbage. Could you make
sure the test verifies that the tested function doesn't write past
the end of the provided buffer (by checking for the garbage value)?

Finally, I removed the extraneous "test disabled" text from the
rw_info() statements (probably copy-and-paste mistakes :)

With the patch applied and the suggested changes to test for the
potential corruption of the destination buffer, please go ahead
and commit the test.

Thanks
Martin

PS I added rw_narrow() overloads that you could use to display the
contents of the (wide) destination buffer until we have the formatting
directive implemented (I'm working on it).

Also, I noticed some strange long --trace output in a few cases that
doesn't look right to me (see below). Could you look into it to see
what's going on? (Is it because we're not using the right formatting
directive?)

# ITRACE_ASSERTION (S0) (4 lines):
# TEXT: line 215. std::basic_string<wchar_t, char_traits<wchar_t>, 
allocator<wch
ar_t>>({ 'x' <repeats 4095 times> }).copy ("\0", 4095) expected 
"\0\0\0x\0\0\0x\
0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0
...
\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0", got 
"\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\
...
0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0x\0\0\0
x\0\0\0"
# CLAUSE: lib.string.copy
# LINE: 133