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:<Maxim.Kozlovsky@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC010E1E89D8@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 25 Feb 2010 14:17:59 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: Please review
Message-ID: <20100225141759.7086a83b@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010E1E89D8@cosmail02.lsi.com>
References: <861DA0537719934884B3D30A2666FECC010E178D8C@cosmail02.lsi.com>
	<20100223115407.0d1029c8@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010E1E82C6@cosmail02.lsi.com>
	<20100225134646.1409dac7@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010E1E89D8@cosmail02.lsi.com>
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 Thu, 25 Feb 2010 14:55:40 -0700 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> Don't know what your problem with "bool" is, it is part of C
> standard. Never bit me in the ass or any other place as long as I've
> been using it, after the compilers implemented proper bool built-in
> type support. We don't live in 80s anymore. It is true that doing
> that was not a good idea until gcc 4.0 (or 3.x something), but times
> have changed.
> 
> >      line 717 this looks like a good candidate for an inline
> > [MK] It will be inlined anyway if the compiler thinks it is a good
> > candidate. It is a good practice to never add inline to static
> > routines in .c files because they might grow and stop being good
> > inline candidates.
> 
> I was implying that it be moved to a .h.  I don't think the compiler
> will inline it, because it's called from other modules, is it not?
> I mean, why else preserve it.  It's better practice not to obfuscate
> behind what a compiler might do.   If it changes, then it might need
> to be changed. That's true of every line of code.
> [MK] It is static now, can't be called from other modules.

Ok, then why keep it?

> linux/kernel/linux-mips-2.6/net/neteee2/eee-timer.c
> 
>      line 287 should we combine these two ifdef 0/later sections?
> [MK] Next change I have pending removes that #ifdef 0, so no need to
> combine.
> 
> 
