On 9/19/19 10:50 AM, Daniel P. Berrangé wrote:
> To get some slightly less made-up stats, I did some searching:
>
> - 4408 methods with an 'errp' parameter declared
>
> git grep 'Error \*\*errp'| wc -l
>
> - 696 methods with an 'Error *local' declared (what other names
> do we us
18.09.2019 16:02, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here is a proposal (three of them, actually) of auto propagation for
> local_err, to not call error_propagate on every exit point, when we
> deal with local_err.
>
> It also may help make Greg's series[1] about error_append_hint
On Thu, Sep 19, 2019 at 04:16:25PM +, Vladimir Sementsov-Ogievskiy wrote:
> 19.09.2019 18:50, Daniel P. Berrangé wrote:
> > On Thu, Sep 19, 2019 at 10:24:20AM -0500, Eric Blake wrote:
> >> On 9/19/19 9:49 AM, Daniel P. Berrangé wrote:
> >>
> ALWAYS using MAKE_ERRP_SAFE() on entry to any fu
19.09.2019 18:50, Daniel P. Berrangé wrote:
> On Thu, Sep 19, 2019 at 10:24:20AM -0500, Eric Blake wrote:
>> On 9/19/19 9:49 AM, Daniel P. Berrangé wrote:
>>
ALWAYS using MAKE_ERRP_SAFE() on entry to any function that has an Error
**errp parameter is dirt-simple to explain. It has no per
On Thu, Sep 19, 2019 at 10:24:20AM -0500, Eric Blake wrote:
> On 9/19/19 9:49 AM, Daniel P. Berrangé wrote:
>
> >> ALWAYS using MAKE_ERRP_SAFE() on entry to any function that has an Error
> >> **errp parameter is dirt-simple to explain. It has no performance
> >> penalty if the user passed in a n
19.09.2019 18:24, Eric Blake wrote:
> On 9/19/19 9:49 AM, Daniel P. Berrangé wrote:
>
>>> ALWAYS using MAKE_ERRP_SAFE() on entry to any function that has an Error
>>> **errp parameter is dirt-simple to explain. It has no performance
>>> penalty if the user passed in a normal error or error_abort
On 9/19/19 9:49 AM, Daniel P. Berrangé wrote:
>> ALWAYS using MAKE_ERRP_SAFE() on entry to any function that has an Error
>> **errp parameter is dirt-simple to explain. It has no performance
>> penalty if the user passed in a normal error or error_abort (the cost of
>> an 'if' hidden in the macro
19.09.2019 17:44, Eric Blake wrote:
> On 9/19/19 9:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>
>>>
>>> To the same topic, of minimization: should we always call MAKE_ERRP_SAFE at
>>> function top, or only
>>> in block, where it is needed (assume, we dereference it only inside some
>>> "if" or "
On Thu, Sep 19, 2019 at 09:44:14AM -0500, Eric Blake wrote:
> On 9/19/19 9:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> >>
> >> To the same topic, of minimization: should we always call MAKE_ERRP_SAFE
> >> at function top, or only
> >> in block, where it is needed (assume, we dereference it onl
19.09.2019 17:12, Vladimir Sementsov-Ogievskiy wrote:
> 19.09.2019 16:40, Eric Blake wrote:
>> On 9/19/19 4:17 AM, Kevin Wolf wrote:
>>> Am 18.09.2019 um 19:10 hat Eric Blake geschrieben:
On 9/18/19 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
> + */
> +#define MAKE_ERRP_SAFE(errp) \
>
Am 19.09.2019 um 16:13 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 19.09.2019 16:40, Eric Blake wrote:
> > On 9/19/19 4:17 AM, Kevin Wolf wrote:
> >> Am 18.09.2019 um 19:10 hat Eric Blake geschrieben:
> >>> On 9/18/19 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
> + */
> +#define MAKE
On 9/19/19 9:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
>> To the same topic, of minimization: should we always call MAKE_ERRP_SAFE at
>> function top, or only
>> in block, where it is needed (assume, we dereference it only inside some
>> "if" or "while"?
>> Kevin, is something bad in propaga
On 9/19/19 9:13 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> With my plan of two different macro, I at least messed the case when we need
> both dereferencing and hints, which means third macro, or one macro with
> parameters,
> saying what to wrap.
>
> And my aim was to follow the idea of "do p
13 matches
Mail list logo
