From: David Abrahams (dave_at_[hidden])
Date: 2007-11-05 13:28:45
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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk