Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/miscfs/genfs
On Thu, Mar 13, 2014 at 12:32:38AM +0900, Mindaugas Rasiukevicius wrote:
> Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>
> wrote:
> > Date: Wed, 12 Mar 2014 16:16:32 +0200
> > From: Jukka Ruohonen <jruohonen%iki.fi@localhost>
> >
> > On Wed, Mar 12, 2014 at 09:39:23AM +0000, Juergen Hannken-Illjes wrote:
> > > Restructure layer_lock() to always lock before testing for dead node.
> > > Use ISSET() to test flags, add assertions.
> >
> > As I wrote in the manual page, I'd rather see ISSET(3) et. al.
> > disappear, i.e. these obscure rather than clarify...
> >
> > I disagree. Phrases like `(vp->v_iflag & (VI_XLOCK | VI_CLEAN)) == 0'
> > make my head's parser stumble -- there are just enough complements to
> > juggle that it overwhelms my brain registers for the fast path. I'd
> > rather read `!ISSET(vp->v_iflag, (VI_XLOCK | VI_CLEAN))'.
>
> I disagree. For kernel developers, that kind of bitwise arithmetics and
> masking ought to be intuitive. If there is more logic and it gets long,
> then separate it:
>
> const bool foobar = (mask & (FOO | BAR)) == 0;
> const bool baz = (mask & BAZ) != 0;
>
> if (foobar && baz) ...
Except you really don't want the compiler to convert the value to
a 'bool'.
> ISSET() is somewhat okay (although I do not use it), but I particularly
> dislike __BIT() as I forget whether the 1st bit is n = 0 or whether this
> API tries to be fancy and it is n = 1. 1U << n is just straigtforward.
Or number from the other end...
Indeed, I have to go away and find the definitions and then realise
that they are just longhand!
I don't normally compare bit masking against zero, just:
if (var & BIT)
or
if (!(var & BIT))
to me they read better that way.
David
--
David Laight: david%l8s.co.uk@localhost
Home |
Main Index |
Thread Index |
Old Index