This is the mail archive of the
mailing list for the libstdc++ project.
Re: Regression(?) on the 3.2 branch: 23_containers/vector_capacity.cc execution test
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 10 Dec 2002 12:07:18 -0600
- Subject: Re: Regression(?) on the 3.2 branch: 23_containers/vector_capacity.cc execution test
- References: <Pine.BSF.email@example.com>
>From '2002-11-24 05:00 UTC' to '2002-12-09 04:00 UTC' appeared:
>FAIL: 23_containers/vector_capacity.cc execution test
>on the 3.2 branch for all newlib targets (mmix-knuth-mmixware,
So, roughly this is what is failing:
bool test = true;
v[v.max_size() - 1] = 2002;
catch (const std::bad_alloc& error)
test = true;
catch ( std::exception& error)
std::cout << error.what() << std::endl;
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/03.cc or
Well, the organization can certainly be improved.
I'm not a fan of adding files like "03.cc" 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.