Using _GLIBCPP_RESOLVE_LIB_DEFECTS in the testsuite?

[Doug Gregor <dgregor at apple dot com>]

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