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 "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 > post-conversion > > 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 > boilerplate). > > Having to think 'does this method require me to use MAKE_ERRP_SAFE, or > can I omit it?' does not provide the same simplicity. >
Interesting: it's another story, but with this macro used in each errp-function we can collect the whole call-stack of the error int Error object, and report it. It may be not good for end-user, but very useful for testing. Or is it bad idea? Anyway, I often have the problem: I have some error reported, and need to understand where was it from.. git grep helps, but backtrace would be a lot better. -- Best regards, Vladimir
