[dpdk-dev] [PATCH] librte_eal/common: fix return type of rte_bsf64
Tyler Retzlaff
roretzla at linux.microsoft.com
Sat Mar 13 02:10:07 CET 2021
On Fri, Mar 12, 2021 at 10:13:30PM +0100, Morten Brørup wrote:
> > >
> > > Please also update the similar math functions in rte_common.h, so the
> > return type is consistent across these functions:
> > > - rte_bsf32()
> > > - rte_bsf32_safe()
> > > - rte_fls_u32()
> > > - rte_bsf64()
> > > - rte_fls_u64()
> > > - rte_log2_u32()
> > > - rte_log2_u64()
> >
> > agreed, happy to review the whole set and deal with it all at once.
>
> Ups. I should have omitted rte_bsf32_safe() from the list. It returns a Boolean.
if we can agree that we can use C11 as a base we could just do away with
all this dumb 32-bit vs 64-bit static selection at the call site (at
least for rte_bsf32() and rte_bsf64() and probably others).
i could just introduce the following macro and deprecate the current
inline functions.
#define rte_bsf(v) \
(uint32_t)_Generic((v), \
uint8_t: __builtin_ctz, \
uint16_t: __builtin_ctz, \
uint32_t: __builtin_ctz, \
default: __builtin_ctzll)(v)
uint8_t a = ...;
uint16_t b = ...;
uint32_t c = ...;
uint64_t d = ...;
the following would jw as intended, though given the range of the value
that may be returned we could narrow the cast to uint8_t so we don't
have to sprinkle casts in places where usage like uint8_t x = rte_bsf(v);
exists.
rte_bsf(a);
rte_bsf(b);
rte_bsf(c);
rte_bsf(d);
anyway, if people care let me know otherwise i'm just going to review
and fix what is already there.
More information about the dev
mailing list