[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] error: auto propagated local_err

From: Eric Blake
Subject: Re: [RFC] error: auto propagated local_err
Date: Thu, 19 Sep 2019 09:44:14 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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 propagation, when it not related to error_abort?
> Or, even, we may use MAKE_ERRP_SAFE on every function, which have Error 
> **errp argument, even if we neither
> dereference it nor append hints? Is it what you propose by "SINGLE paradigm"? 
> It's of course simpler to script,
> to check in checkpatch and to maintain.

Yes. The simpler we make the rules, and the less boilerplate it entails,
the more likely that we can:

a) avoid exceptions and corner cases that cost review time
b) automate the conversion into complying with the rule
c) codify those rules in syntax check to ensure they are followed

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 is probably negligible compared to
everything else we do), and has no semantic penalty if the user passed
in NULL or error_fatal (we now get the behavior we want with less

Having to think 'does this method require me to use MAKE_ERRP_SAFE, or
can I omit it?' does not provide the same simplicity.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]