All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.