[dpdk-stable] [dpdk-dev] [PATCH v2 1/2] net/avp: fix gcc 10 maybe-uninitialized warning

[Kevin Traynor]

On 12/03/2020 13:25, Ferruh Yigit wrote:
> On 3/11/2020 11:32 AM, Kevin Traynor wrote:
>> gcc 10.0.1 reports:
>>
>> ../drivers/net/avp/avp_ethdev.c: In function ‘avp_xmit_scattered_pkts’:
>> ../drivers/net/avp/avp_ethdev.c:1791:24:
>> warning: ‘avp_bufs[count]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>>  1791 |   tx_bufs[i] = avp_bufs[count];
>>       |                ~~~~~~~~^~~~~~~
>> ../drivers/net/avp/avp_ethdev.c:1791:24:
>> warning: ‘avp_bufs[count]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>>
>> Fix by intializing the array.
>>
>> Fixes: 295abce2d25b ("net/avp: add packet transmit functions")
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Kevin Traynor <ktraynor at redhat.com>
>> ---
>> v2: no change
>>
>> note, commit log violates line length but I didn't want to split warning msg.
>>
>> Cc: allain.legacy at windriver.com
>> Cc: Steven Webster <steven.webster at windriver.com>
>> Cc: Matt Peters <matt.peters at windriver.com>
>> ---
>>  drivers/net/avp/avp_ethdev.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
>> index cd747b6be..1abe96ce5 100644
>> --- a/drivers/net/avp/avp_ethdev.c
>> +++ b/drivers/net/avp/avp_ethdev.c
>> @@ -1695,5 +1695,5 @@ avp_xmit_scattered_pkts(void *tx_queue,
>>  {
>>  	struct rte_avp_desc *avp_bufs[(AVP_MAX_TX_BURST *
>> -				       RTE_AVP_MAX_MBUF_SEGMENTS)];
>> +				       RTE_AVP_MAX_MBUF_SEGMENTS)] = {};
>>  	struct avp_queue *txq = (struct avp_queue *)tx_queue;
>>  	struct rte_avp_desc *tx_bufs[AVP_MAX_TX_BURST];
>>
> 
> Isn't this a false positive, can there be any case 'avp_bufs[]' used
> uninitialized? Or am I missing something.
> 

I presume it's because it's not being initialized in the fn and there is
some paths in fn's it's passed to that don't initialize it. Of course in
practice with "normal" values this might not happen.

> If this is false positive, does it worth to report to issue to gcc?
>