linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Allison Collins <allison.henderson@oracle.com>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: Fix compiler warning in xfs_attr_shortform_add
Date: Sun, 26 Jul 2020 17:27:27 -0700	[thread overview]
Message-ID: <d64b2e38-e9fc-b19f-d647-361287a76917@sandeen.net> (raw)
In-Reply-To: <cc8bd065-7990-eee7-de49-fc29a6a8e45a@oracle.com>

On 7/26/20 11:10 AM, Allison Collins wrote:
> 
> 
> On 7/25/20 11:48 PM, Eric Sandeen wrote:
>> On 7/25/20 4:01 PM, Allison Collins wrote:
>>> @@ -730,7 +730,8 @@ xfs_attr_shortform_add(
>>>       ASSERT(ifp->if_flags & XFS_IFINLINE);
>>>       sf = (xfs_attr_shortform_t *)ifp->if_u1.if_data;
>>>       error = xfs_attr_sf_findname(args, &sfe, NULL);
>>> -    ASSERT(error != -EEXIST);
>>> +    if (error == -EEXIST)
>>> +        return error;
>>>         offset = (char *)sfe - (char *)sf;
>>>       size = XFS_ATTR_SF_ENTSIZE_BYNAME(args->namelen, args->valuelen);
>>
>> ASSERTs are normally "this cannot happen unless somebody made a
>> programming mistake," not an error that can actually happen in normal
>> use.
>>
>> So now it's being handled as a normal error. (here and in other places
>> in these patches)
>>
>> Is -EEXIST an error that should be handled, or if we get it does that
>> indicate that somebody made a coding mistake?
>>
>> I ask because "fix compiler warnings" don't usually turn into
>> "add a bunch of new error handling" so ... some extra explanation would
>> be helpful for these changes.
> I see. At this point in the attr process, if this error happens, I would call it "a programming mistake" of sorts.  This condition of the attr already existing is handled much earlier in the code, so this error code path really shouldn't ever execute at this point unless something weird happened.
> 
> Should I have both the assert and the error handling for the compiler warning?  I wasn't really sure how concerned people actually were about the warnings.  It's not really that the variable is unused, it's just only used for the assert.

hi Allison -

Well, it really is unused if #ifdef DEBUG isn't set.  :)  And we do want to eliminate gcc warnings so you're doing the right thing by addressing them.

If these are typical ASSERTs which are "debug only, should never happen, if it does you broke the code" then I'd say wrap the variable declarations in

#ifdef DEBUG
	int foo;
#endif

it's ugly, but we do it in many places.

if it's a real, possible error that actually needs to be handled at runtime then the way you've done it makes sense, I'd just suggest a commit log that explains the rationale for the change.

Sorry for not being conversant enough in this code to know the difference between the two, it just kind of stuck out at me to see ASSERTs being turned into error handlers as a response to compiler warnings.

Thanks
-Eric

  reply	other threads:[~2020-07-27  0:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-25 23:01 [PATCH 0/2] xfs: Fix compiler warnings Allison Collins
2020-07-25 23:01 ` [PATCH 1/2] xfs: Fix compiler warning in xfs_attr_node_removename_setup Allison Collins
2020-07-25 23:01 ` [PATCH 2/2] xfs: Fix compiler warning in xfs_attr_shortform_add Allison Collins
2020-07-26  6:48   ` Eric Sandeen
2020-07-26 18:10     ` Allison Collins
2020-07-27  0:27       ` Eric Sandeen [this message]
2020-07-27  1:57         ` Allison Collins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d64b2e38-e9fc-b19f-d647-361287a76917@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=allison.henderson@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).