Date: Mon, 29 Mar 2004 23:59:52 -0800 (PST) From: Nate Lawson <nate@root.org> To: Julian Elischer <julian@elischer.org> Cc: David O'Brien <obrien@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/kern subr_bus.c Message-ID: <20040329235454.F78512@root.org> In-Reply-To: <Pine.BSF.4.21.0403240108230.35223-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0403240108230.35223-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Mar 2004, Julian Elischer wrote: > On Wed, 24 Mar 2004, David Schultz wrote: > > > On Mon, Mar 22, 2004, David O'Brien wrote: > > > On Mon, Mar 22, 2004 at 06:06:48PM -0800, Nate Lawson wrote: > > > > > + if (bootverbose && flags & INTR_MPSAFE) > > > .. > > > > I recommend you parenthesize (flags & INTR_MPSAFE). > > > > > > man operator :-) > > > > For some reason, gcc complains about the lack of excessive > > parentheses for expressions like 'a && b || c' and > > 'foo >> shift1 + shift2', but not for 'a && b & c'. > > It's too bad there's no documentation on which parts of > > operator(7) are supposed to be considered obvious (along > > with a note that =='s priority over & is a mistake---that > > one often bites me.) > > > > I agree. it is often late at night when staring at code looking for a > bug that one fails to notice the subtlties of operator precedence. > > One person's "obvious" is not always obvious to others. Especially if > one has noticed differences in precedence between different languages > one has worked with in one's life. > > a couple of extra parens on a statement with 'non-normal' form > such as that above can save hours later. I agree with one exception -- when parens are used in an overly obvious way (like MDAS) or in an attempt to force precedence (which they cannot do.) Parens only indicate associativity, they cannot override precedence. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040329235454.F78512>