From: Harvey Harrison <harvey.harrison@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-ide <linux-ide@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 5/11v2] ata: replace macro with static inline in libata.h
Date: Fri, 15 Feb 2008 15:08:50 -0800 [thread overview]
Message-ID: <1203116930.30938.12.camel@brick> (raw)
In-Reply-To: <20080215225339.0e2ed4e6@core>
On Fri, 2008-02-15 at 22:53 +0000, Alan Cox wrote:
> > > NAK. This is a sparse bug, fix sparse.
> >
> > Yes, fair enough, but that's not all the patch is about.
> >
> > 1) it's using a max_t and min_t to force the comparisons as shorts, why
> > not just make it a static inline?
>
> Because max_t and min_t also force the comparsion types
Umm, maybe I'm missing something then, but how does the static inline
not do this?
>
> > 2) the static inline is a little clearer about the intent here.
>
> Why ?
OK, maybe not much clearer. But isn't the inline easier to see at
a glance that it is returning a value constrained to be
vmin <= v <= vmax
I suppose the variable names make it clear, but the macro construction
is (slightly) less obvious.
>
> > 3) the sparse warnings are entirely secondary (and technically correct
> > when the macros expand, __x is shadowed)
>
> In a controlled manner. I guess you could make min and max use __x and __y
>
__mint __maxt...but I'm not proposing that.
> > 4) I may be mistaken, but I thought then when something can be written
> > as a static inline instead of a macro it was preferred. At least I've
> > seen akpm say so, but I'll let him speak for himself (added to CC:)
>
> gcc still sometimes seems to optimise macros better than inlines.
OK, I didn't realize that, any pointers?
Harvey
next prev parent reply other threads:[~2008-02-15 23:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-15 22:06 [PATCH 5/11v2] ata: replace macro with static inline in libata.h Harvey Harrison
2008-02-15 22:30 ` Alan Cox
2008-02-15 22:46 ` Harvey Harrison
2008-02-15 22:53 ` Alan Cox
2008-02-15 23:08 ` Harvey Harrison [this message]
2008-02-16 0:05 ` Alan Cox
2008-02-16 0:23 ` Harvey Harrison
2008-02-16 0:36 ` Harvey Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1203116930.30938.12.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.