Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-11-05 13:28:45

on Mon Nov 05 2007, "Martin Bonner" <> wrote:

> From: David Abrahams
>> on Thu Nov 01 2007, Beman Dawes <> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at