on Mon Nov 05 2007, "Martin Bonner" <Martin.Bonner-AT-pi-shurlok.com> wrote:
From: David Abrahams
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
I don't know how to do that for system specific fixes on platforms Boost isn't testing and I don't have access to. For libraries like Boost.System and Boost.Filesystem I have to take such patches on faith. Of course I inspect them to make sure they appear reasonable and don't affect other platforms.
The person submitting the patch surely describes to you the problem the patch should be fixing, no?
If you don't have access to the platform, create a test and tweak until it fails in the way described.
I don't see how you can do that with system specific errors. Consider: "The foobarfs file system returns duff information if stat is called twice in succession on the same file. Fix by calling stat on /dev/null after each call to stat (unless calling stat on /dev/null, in which case call stat on / first.)"
I don't see how you could possibly rig up a test case for that unless you have a system with foobarfs to hand.
Okay, if it's not one of the configurations we're testing, you have a point.
Alternatively, how about a compiler which won't accept valid code, but will accept some invalid code to perform the equivalent operation? How do you write a test case for that without the compiler?
If you have a patch (that's the scenario), presumably you know what the invalid code workaround looks like. Anyway, I'm not trying to be an absolutist about this; it's just that I think the exceptions are very rare. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com