AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Rendell.Fong@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	1255562946.20354.46.camel@rendellf
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 14 Oct 2009 16:41:28 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: Rendell Fong <Rendell.Fong@lsi.com>
Subject: Re: please review 33340
Message-ID: <20091014164128.4dfbd65f@ripper.onstor.net>
In-Reply-To: <1255562946.20354.46.camel@rendellf>
References: <20091014145402.4b5cbe85@ripper.onstor.net>
	<1255558385.20354.36.camel@rendellf>
	<20091014161210.463af7b3@ripper.onstor.net>
	<1255562946.20354.46.camel@rendellf>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 14 Oct 2009 17:29:06 -0600 Rendell Fong <Rendell.Fong@lsi.com>
wrote:

> On Wed, 2009-10-14 at 17:12 -0600, Andrew Sharp wrote:
> > On Wed, 14 Oct 2009 16:13:05 -0600 Rendell Fong
> > <Rendell.Fong@lsi.com> wrote:
> > 
> > > On Wed, 2009-10-14 at 15:54 -0600, Andrew Sharp wrote:
> > > > Change 33340 by andys@ripper on 2009/09/15 14:27:51 *pending*
> > > > 
> > > >         cleanup of nfx-tree in tuxrx branch after recent merge
> > > > from various personal trees and dev branch.
> > > >         
> > > >         reviewed by
> > > > 
> > > > Affected files ...
> > > > 
> > > > ... //depot/tuxrx/nfx-tree/code/neteee2/eee-ipc.c#2 edit
> > > ok
> > > > ... //depot/tuxrx/nfx-tree/code/sm-testdump/testdump-api.c#2
> > > > edit
> > > ok
> > > > ... //depot/tuxrx/nfx-tree/code/sm-testdump/testdump-common.c#2
> > > > edit
> > > ok
> > > > ... //depot/tuxrx/nfx-tree/code/sm-testdump/testdump-dump.c#1
> > > > edit
> > > ok
> > > > ... //depot/tuxrx/nfx-tree/code/sm-testdump/testdump-restore.c#3
> > > > edit
> > > ok
> > > > ... //depot/tuxrx/nfx-tree/code/ssc-vsd/vs-daemon.c#3 edit
> > > I know its not your code, but why use a do while loop in the first
> > > place when it will only loop once?  A set of brackets would be
> > > sufficient.
> > 
> > The reason this is done this way is so that the use of the macro
> > looks like a function call does:
> > 
> > 	foo_func(argthis, argthat);
> > 
> > 	FOO_MACRO(argthis, argthat);
> > 
> > 	FOO_MACRO(argthis, argthat)
> > 
> > People get freaked by the third example.  The loop gets optimized
> > away by the compiler because of the zero, and the programmer can
> > still use the semicolon at the end w/o complaints from gcc.
> 
> 
> Forgot to mention that there's 10 other macros in this file that use
> do while (FALSE) loops.  Why change 2 of them but not the rest?
> Also, TRUE and FALSE is used throughout this code (which is not
> running in the kernel).

Why did I do these two, or this file at all, well, that I couldn't tell
you other than there must have been some kind of compiler warning that
led me here, or some other situation where I ended up here.  Actually, I
have no recollection.  I didn't notice that there were any others in the
file.

The notion of a macro of this type, using the { ... } while(0) trick is
utterly abhorrent if you throw in some arbitrary typedef or macro
instead of '0'.  With the unnecessary obfuscation, it just makes the
whole thing confusing and difficult to maintain.  But a zero is
instantly recognizable and understandable what's going on, and trivial
to maintain because of that.

I can revert the change to this file or change all the rest in the
file, your call.
