Using _GLIBCPP_RESOLVE_LIB_DEFECTS in the testsuite?

[Doug Gregor]

Hello,
   How should we handle test cases that pass/fail depending on the state 
of _GLIBCPP_RESOLVE_LIB_DEFECTS? For instance, in the test file 
23_containers/list_operators.cc, the function test02() does a bit of 
splicing. In the last part of the test, it is assumed that splicing 
does not invalidate iterators:

   // result should be [2 1 3 4 5]
   ++i;
   list0201.splice(list0201.begin(), list0201, i);
   VERIFY(list0201 != list0202);
   VERIFY(list0201 == list0203);

   // result should be [1 3 4 5 2]
   list0201.splice(list0201.end(), list0201, i);
   VERIFY(list0201 == list0204);

In the C++98 standard, splice would invalidate the iterator i (see 
23.2.2.4), making the behavior of the last call undefined. DR 250 
changes the semantics of splice such that it does not invalidate the 
iterators spliced in, so the iterator i is still valid and the code is 
correct. The snippet above implicitly assumes the semantics in the DR.

Should the snippet be changed to, e.g., :

   // result should be [2 1 3 4 5]
   ++i;
   list0201.splice(list0201.begin(), list0201, i);
   VERIFY(list0201 != list0202);
   VERIFY(list0201 == list0203);

   // result should be [1 3 4 5 2]
#ifndef _GLIBCPP_RESOLVE_LIB_DEFECTS?
   // 250. splicing invalidates iterators
   i = list0201.begin();
#endif
   list0201.splice(list0201.end(), list0201, i);
   VERIFY(list0201 == list0204);

?

In this specific instance, it doesn't matter much because splice() 
never had a reason to invalidate iterators. However, I'm implementing a 
debug mode and the distinction does matter (because the testcase fails 
without the DR semantics).

	Doug