Howdy guys. Sorry for the crosspost. Patch to speed up taglib.

[Scott Wheeler]

Lukáš Lalinský wrote:
> Well, but this is precisely the point of unit testing for specific
> parts of your code. You define well-known good states in the unit
> tests, and if the code ends up in an undefined state, you assume it's
> broken. The problem is have a good test coverage of the file format
> specifications. IME, having a sizeable curpus of files and doing
> playable/unplayable tests is nice in early stages of writing code for
> a new format and experimenting, but not if you try to ensure that the
> code follows some specification.
>
> As an example, ByteVector::rfind is currently broken and
> tests/toolkit-test.cpp tells you so, but it have been like that for
> quite some time. Fortunatelly, no code uses that specific code path,
> but if somebody (like me) tries to use it in a new file format and the
> code doesn't work in some cases, having a specific test suite is more
> useful to identify the problem than doing some high-level tests over a
> music collection.
I completely agree, but that still doesn't catch a lot of the bugs in 
something like TagLib. Unit tests generally won't tell you if you're 
conforming to a given spec (unless you write enough tests to verify the 
spec, in which case for TagLib the test suite would probably be bigger 
than the library).

As for the toolkit stuff, that is caught in the release process since my 
script that generates the tarball runs the (far too few) unit tests and 
doesn't generate if one fails.

-Scott