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 >
