This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Regression(?) on the 3.2 branch: 23_containers/ execution test

>From '2002-11-24 05:00 UTC' to '2002-12-09 04:00 UTC' appeared:
>FAIL: 23_containers/ execution test
>on the 3.2 branch for all newlib targets (mmix-knuth-mmixware,

So, roughly this is what is failing:

void test03()
  bool test = true;
  std::vector<int> v;
      v[v.max_size() - 1] = 2002;
  catch (const std::bad_alloc& error)
      test = true;

  catch ( std::exception& error)
	std::cout << error.what() << std::endl;

  catch (...)
      test = false;
  VERIFY( test );

You might see if that, with the cout bits, is more illuminating.

>It doesn't help bug-tracking, that the way the libstdc++-v3
>project adds to the testsuite by *modifying* existing named


It's my opinion that a testsuite designed for bug tracking is less
useful than a testsuite designed to test conformance. Reasonable people
may differ, and have. The libstdc++ testsuite is organized around
conformance: some of the other gcc projects, including gcc/g++, have
organized around bug tracking and regression testing.

>Can the libstdc++-v3 project please consider adding *files* when
>adding to the test-suite?  For example, the added test could
>have been testsuite/23_containers/vector_capacity/ or

Well, the organization can certainly be improved. 

I'm not a fan of adding files like "" to a testsuite, as I don't
believe that it's helpful in the long run, even if it does contain only
one bug. If you've ever worked with large, commercial testsuites that
implement this kind of organization, you will quickly see how unhelpful
this becomes as the tests multiply and you attempt to figure out what,
at a glance, is wrong. At least with the current organization, you,
without much effort, could tell the failure was within the general range
of vector capacity, as indicated in chapter 23 of the standard.

In general, I'd like to keep this kind of structure. As the tests become
more and more involved, I'm suggesting that tests like
23_containers/vector_capacity get broken down into things like



There is considerable cleanup to do with respect to this in the 27_io directory.

Your thought to make sub directories was interesting, but seems
difficult given the constraints of CVS, and its known issues dealing
with directories and renames. Thanks for suggesting it, however.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]