Re: [v3] libstdc++/54296

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 29/08/2012, François Dumont wrote:
> On 08/29/2012 02:12 AM, Jonathan Wakely wrote:
>> On 28 August 2012 11:08, François Dumont  wrote:
>>>      (erase(const key_type&)): Use latters.
>> Let's put "Use the new member functions" here in the ChangeLog, I
>> don't think you can make a plural out of "latter" :-)
>>
>>>      * testsuite/23_containers/unordered_map/erase/54296.cc: New.
>>>      * testsuite/23_containers/unordered_multimap/erase/54296.cc: New.
>>>
>>> Tested under linux x86_64.
>> Thanks for the fix.  Did you manage to test it with valgrind?
>>
>      No, I haven't test it with Valgrind. I prefered to try hard to
> create a test case showing the problem without it.

Of course it's great if the problem can be isolated and distilled to
something suitable for the testsuite, but I also like to run extra
tests of my own to convince myself the code is correct. Those tests
might take several minutes to run, or rely on huge input files, or
rely on user input. Sometimes modifying such tests to work in the
testsuite (i.e. automated and with a simple pass/fail status) is
difficult or impossible, but I can still run them (and not commit
them) to be more confident the code is correct.

>      You and others regularly ask to run tests with Valgrind. Is there
> an easy way to run tests of the testsuite through Valgrind ?

I don't think so.

> Some
> variable to customize when invoking 'make check' ? I don't want to do a
> 'make install' when building the trunk and 'make check' correctly build
> and run tests using the trunk build. This is why I prefer to work
> entirely in the libstdc++ testsuite context.

That is a good thing to aim for, but in some cases it relies on you
predicting the possible ways the code could fail and writing tests for
it. By using valgrind I often find issues in code that seems to work
and passes the tests I'd written, but is actually still buggy. Once I
know there's a bug I can investigate it and then produce automated
tests, but I wouldn't have found the bug without valgrind.

Basically, valgrind can identify bugs that are very hard to find otherwise.

It's very easy to install and use, there's no good reason not to use it.