qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH 02/17] block: Pass local error object pointer to


From: John Snow
Subject: Re: [Qemu-block] [PATCH 02/17] block: Pass local error object pointer to error_append_hint()
Date: Tue, 17 Sep 2019 15:10:00 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


On 9/17/19 10:46 AM, Kevin Wolf wrote:
> Am 17.09.2019 um 16:39 hat Eric Blake geschrieben:
>> On 9/17/19 5:20 AM, Greg Kurz wrote:
>>> Ensure that hints are added even if errp is &error_fatal or &error_abort.
>>>
>>> Signed-off-by: Greg Kurz <address@hidden>
>>> ---
>>>  block/backup.c       |    7 +++++--
>>>  block/dirty-bitmap.c |    7 +++++--
>>>  block/file-posix.c   |   20 +++++++++++++-------
>>>  block/gluster.c      |   23 +++++++++++++++--------
>>>  block/qcow.c         |   10 ++++++----
>>>  block/qcow2.c        |    7 +++++--
>>>  block/vhdx-log.c     |    7 +++++--
>>>  block/vpc.c          |    7 +++++--
>>>  8 files changed, 59 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/block/backup.c b/block/backup.c
>>> index 763f0d7ff6db..d8c422a0e3bc 100644
>>> --- a/block/backup.c
>>> +++ b/block/backup.c
>>> @@ -602,11 +602,14 @@ static int64_t 
>>> backup_calculate_cluster_size(BlockDriverState *target,
>>>                      BACKUP_CLUSTER_SIZE_DEFAULT);
>>>          return BACKUP_CLUSTER_SIZE_DEFAULT;
>>>      } else if (ret < 0 && !target->backing) {
>>> -        error_setg_errno(errp, -ret,
>>> +        Error *local_err = NULL;
>>
>> Can we go with the shorter name 'err' instead of 'local_err'?  I know,
>> we aren't consistent (both styles appear throughout the tree), but the
>> shorter style is more appealing to me.
> 
> I like local_err better because it's easier to distinguish from errp.
> The compiler might catch it if you use the wrong one because one is
> Error* and the other is Error**, but as a reviewer, I can still get
> confused.
> 
> Kevin
> 

Doesn't that sound like a striking reason for condemnation of this
entire model?

What's going to prevent us from regressing on this technicality in the
future?



reply via email to

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