Re: [dpdk-dev] [PATCH v3 17/24] rte_byteorder.h: explicit cast for return promotion

[Andy Green <andy@warmcat.com>]

On 05/14/2018 12:59 AM, Thomas Monjalon wrote:
> 12/05/2018 04:00, Andy Green:
>> --- a/lib/librte_eal/common/include/generic/rte_byteorder.h
>> +++ b/lib/librte_eal/common/include/generic/rte_byteorder.h
>> @@ -123,7 +123,7 @@ typedef uint64_t rte_le64_t; /**< 64-bit little-endian value. */
>>   static inline uint16_t
>>   rte_constant_bswap16(uint16_t x)
>>   {
>> -	return RTE_STATIC_BSWAP16(x);
>> +	return (uint16_t)RTE_STATIC_BSWAP16((uint16_t)x);
>>   }
> 
> x is already uint16_t, and RTE_STATIC_BSWAP16 is already casting to uint16_t.
> So why these casts are needed?


After winding dpdk back inside lagopus without this patch and recooking 
everything...

In file included from 
/projects/lagopus/src/dpdk/build/include/rte_byteorder.h:15,
                  from /projects/lagopus/src/dataplane/dpdk/pktbuf.h:27,
                  from ./ofproto/mbtree.c:50:
/projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h: In 
function 'rte_constant_bswap16':
/projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h:54:45: 
warning: conversion from 'int' to 'uint16_t' {aka 'short unsigned int'} 
may change value [-Wconversion]
   ((((uint16_t)(v) & UINT16_C(0x00ff)) << 8) | \
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
    (((uint16_t)(v) & UINT16_C(0xff00)) >> 8))
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h:126:9: 
note: in expansion of macro 'RTE_STATIC_BSWAP16'
   return RTE_STATIC_BSWAP16(x);
          ^~~~~~~~~~~~~~~~~~

> And why not in rte_constant_bswap32/64?

It's likely also needed there.  I removed the second cast and then 
repeated the fix on 32/64 as well.

GCC8 building lagopus blowing chunks is my only insight into these api 
header problems in dpdk.  It only blew on bswap16.

I simply want to build lagopus with latest pieces to assess how much 
risk signing up to use lagopus (and its dependencies) ongoing gets me 
into.  So my goal is fix all the build issues around that and then why 
not provide the patches to the projects since they are done by then. 
(My lagopus fixes will have no meaning unless the dpdk fixes get in 
first, so I defer interacting with them).

I can get that to build (I think... I have to pin the dpdk subproject, 
make clean, make dpdk and then finally make to see the warnings 
repeatably) with master dpdk now with my dpdk series of ~45 patches, but 
it requires 25 patches on lagopus and there are still a ton of warnings 
to clean out and an api change about color / metering I just hacked out 
for now.  I didn't look too closely yet but maybe some more dpdk header 
usage issues to come.

-Andy