[dpdk-dev] [PATCH v6 07/12] app/test: clean LTO build warnings (maybe-uninitialized)

Wang, Yipeng1 yipeng1.wang at intel.com
Thu Nov 7 18:48:40 CET 2019


>-----Original Message-----
>From: Andrzej Ostruszka [mailto:amo at semihalf.com]
>Sent: Monday, November 4, 2019 5:48 AM
>To: Wang, Yipeng1 <yipeng1.wang at intel.com>; dev at dpdk.org; Gobriel, Sameh <sameh.gobriel at intel.com>; Richardson, Bruce
><bruce.richardson at intel.com>; Chas Williams <chas3 at att.com>; Burakov, Anatoly <anatoly.burakov at intel.com>
>Cc: mattias.ronnblom at ericsson.com; stephen at networkplumber.org
>Subject: Re: [dpdk-dev] [PATCH v6 07/12] app/test: clean LTO build warnings (maybe-uninitialized)
>
>Yipeng
>
>Thank you for your comment.  See my reply below.
>
>On 11/1/19 6:15 PM, Wang, Yipeng1 wrote:
>>> -----Original Message-----
>[...]
>>> diff --git a/app/test/test_hash_readwrite.c b/app/test/test_hash_readwrite.c
>>> index 4376b099b..615767fb6 100644
>>> --- a/app/test/test_hash_readwrite.c
>>> +++ b/app/test/test_hash_readwrite.c
>>> @@ -298,7 +298,7 @@ test_rw_reader(void *arg)
>>>
>>> 	begin = rte_rdtsc_precise();
>>> 	for (i = 0; i < read_cnt; i++) {
>>> -		void *data;
>>> +		void *data = arg;
>>
>> [Wang, Yipeng]
>> Hi Andrzej, thanks for the fix! Maybe you could initialize the data to be "NULL"?
>> I think it makes more sense to be NULL rather than arg.
>
>That actually is not a good idea.  The conditional test below does not
>check return value from lookup and expects the returned pointer to data
>to be equal to the iteration count (these pointers do not point at
>anything).  For the first loop iteration "data = NULL" could miss the
>problem of the key not being in the hash (key not in the hash, return
>value not checked but the pointer "data" is NULL as we expected since i
>= 0).
>
>What I used is a bit hackish - I assumed that arg pointer (which is
>pointing to the "read_cnt") will not be within [0-read_cnt] address
>range.  If that is too hackish then it would be better to rework this
>function to actually test for return value of hash lookup.  Let me know
>what you think.
>
>Regards
>Andrzej
 [Wang, Yipeng] Thank you for the explanation. I think what you said makes sense.



More information about the dev mailing list