Re: [dpdk-dev] [PATCH] librte_eal/common: fix return type of rte_bsf64

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Fri, Mar 12, 2021 at 08:34:50AM +0100, Morten Brørup wrote:
> CC: ABI Policy maintainers. You might have an opinion. Or not. :-)
> 
> 
> 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.

> 
> They should all return either int or uint32_t.
> 
> Standard C conventions would have them all return int (probably due to C's default type promotion to int when used in calculations), which is also the type returned by their underlying implementation.

yes, i suspect gcc builtins return int because of the default type promotion. probably historical be interesting to get an old gcc hand to tell us a story.

> 
> For some unknown reason, DPDK often uses uint32_t where you would normally use int. I guess it was inspired by MISRA C (for embedded systems); but it is not a documented conventions, and often deviated from.

horses for courses, if it doesn't make sense to interpret as signed then
i don't see a lot of value in using signed and it can open up avenues of
exploit.

> 
> I don't have a personal preference for int or uint32_t here. But at least follow the same convention in the same header file.

agree completely, consistency.

> 
> (Please note that the functions returning a Boolean value as an int type should keep doing that.)

i'm not planning on changing int -> _Bool. but i am curious about your
comment. stdbool.h is already used in the code base is there a compiler
in use that does not support _Bool. this is purely my interest, i don't
propose any change.

> 
> 
> Med venlig hilsen / kind regards
> - Morten Brørup
>