stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: testsuite process helpers
Date Thu, 03 Aug 2006 14:48:07 GMT
Farid Zaripov wrote:
>>-----Original Message-----
>>From: Martin Sebor [] 
>>Sent: Thursday, August 03, 2006 5:10 PM
>>Subject: Re: testsuite process helpers [PATCH]
>>Yes, I suppose you're right. Unless we do some magic with
>>rw_error() and other diagnostic functions:
>>     rw_error(0, 0, 0);   // disables counting errors
>>     rw_error(0, 1, 0);   // disables issuing
>>     rw_error(1, 0, 0);   // enables counting
>>     rw_error(1, 1, 0);   // enables counting and issuing
>>Each call returns the previous state of the diagnostic setting.
>>Or something like that.
>>>  I propose add two functions enable_diag() / 
>>disable_diag(), or just
>>>enable_diag(bool enable)
>>>to the driver (and use any unused bit in _rw_diag_mask). We 
>>can publish
>>>the _rw_diag_mask
>>>along with enum diag_t later when it's will be required.
>>That would be another option. Which one of the two approaches
>>do you like better?
>   I like the variant with rw_enable_diag(bool) because it's requires
> the minimal changes to the driver and gives exactly what is needed.
> I not see the situation when we need temporary disable some
> diag type (or set of diag types) yet.

Okay, let's go with it. How about

rw_enable(int(*)(int, int, const char*, const char*, ...), bool = true);

so that we can simply call it like so:

rw_enable(rw_error, false);   // disable errors
rw_enable(rw_note);           // enable notes

and we don't have to move diag_t into driver.h.

>   The variant with rw_error(0, 0, 0) and other diagnostic functions is
> good and flexible, but it's not clear as for me.

You're right, it is obscure.


View raw message