[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200709271428.l8RES0t8002300@agora.fsl.cs.sunysb.edu>
Date: Thu, 27 Sep 2007 10:28:00 -0400
From: Erez Zadok <ezk@...sunysb.edu>
To: roel <12o3l@...cali.nl>
Cc: Erez Zadok <ezk@...sunysb.edu>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
viro@....linux.org.uk, hch@...radead.org
Subject: Re: [PATCH 13/25] Unionfs: add un/likely conditionals on dir ops
In message <46FAD1D2.8030306@...cali.nl>, roel writes:
> Erez Zadok wrote:
>
> > @@ -194,7 +194,7 @@ int check_empty(struct dentry *dentry, struct unionfs_dir_state **namelist)
> >
> > BUG_ON(!S_ISDIR(dentry->d_inode->i_mode));
> >
> > - if ((err = unionfs_partial_lookup(dentry)))
> > + if (unlikely((err = unionfs_partial_lookup(dentry))))
> > goto out;
> >
> > bstart = dbstart(dentry);
>
> Is it bad to leave this assignment within the unlikely()?
I don't know. Anyone? Will un/likely "break" in the above form?
Actually, it looks like assignments within conditionals are just prohibited
(even if you use double parentheses to shut gcc up :-). It's not mentioned
in the CodingStyle, but it is in scripts/checkpatch.pl. So I'll have to
take out all those assignments out of the conditionals anyway. Good. It
makes code more readable (and besides, most modern compilers will optimize
it just the same).
Cheers,
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists