DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, anatoly.burakov@intel.com
Subject: Re: [dpdk-dev] [PATCH] librte_eal/common: fix return type of rte_bsf64
Date: Wed, 10 Mar 2021 14:52:38 -0800	[thread overview]
Message-ID: <20210310225238.GA10267@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <20210310104942.66ef440e@hermes.local>

On Wed, Mar 10, 2021 at 10:49:42AM -0800, Stephen Hemminger wrote:
> On Tue,  9 Mar 2021 22:41:06 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> 
> > based on the original commit and the usage of rte_bsf64 it appears the
> > function should always have returned uint32_t instead of int which is
> > consistent with the cast introduced in the return statement.
> > 
> > Fixes: 4e261f551986 ("eal: add 64-bit bsf and 32-bit safe bsf
> > functions")
> > Cc: anatoly.burakov@intel.com
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/librte_eal/include/rte_common.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h
> > index 1b630baf1..5e70ee7a8 100644
> > --- a/lib/librte_eal/include/rte_common.h
> > +++ b/lib/librte_eal/include/rte_common.h
> > @@ -679,7 +679,7 @@ rte_fls_u32(uint32_t x)
> >   * @return
> >   *     least significant set bit in the input parameter.
> >   */
> > -static inline int
> > +static inline uint32_t
> >  rte_bsf64(uint64_t v)
> >  {
> >  	return (uint32_t)__builtin_ctzll(v);
> 
> The cast is no longer needed, it should be removed.

it's not so much about making it compile. it's about making it correct
with respect to original author intent, consistent with the rte_bsf32
declaration, other consumers of the inline function inside rte_common.h
and whether or not it makes sense to have a function that returns a
count of bits signed. based on those factors i'm asserting that the
cast is actually correct and it is the return type that is wrong.

your suggestion however would avoid having to deal with the downside of
changing the return type which is that an api change is necessary since
the function is exposed to applications. but even for something small
like this i think it is best to pursue the correct change rather than
sprinkle casts to (uint32_t) at various call-sites.

i'm in the process of sending the proposal to deprecate/change the
return type unless others feel the above evaluation missed the mark.

thanks!

  reply	other threads:[~2021-03-10 22:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10  6:41 Tyler Retzlaff
2021-03-10 18:31 ` Ranjit Menon
2021-03-10 18:49 ` Stephen Hemminger
2021-03-10 22:52   ` Tyler Retzlaff [this message]
2021-03-12  7:34     ` Morten Brørup
2021-03-12 11:46       ` Kinsella, Ray
2021-03-12 18:10         ` Tyler Retzlaff
2021-03-12 18:24       ` Tyler Retzlaff
2021-03-12 21:13         ` Morten Brørup
2021-03-13  1:10           ` Tyler Retzlaff
2021-03-13  7:29             ` Morten Brørup
2021-03-13 16:04               ` Tyler Retzlaff

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=20210310225238.GA10267@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
    --to=roretzla@linux.microsoft.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).