On Fri, Oct 06, 2017 at 01:18:00AM +0100, Ferruh Yigit wrote:
> On 9/11/2017 4:13 PM, Olivier Matz wrote:
> > The compilation with gcc-6.3.0 and EXTRA_CFLAGS=-Og gives the following
> > error:
> >
> > CC rte_lpm6.o
> > rte_lpm6.c: In function ‘rte_lpm6_add_v1705’:
> > rte_lpm6.c:442:11: error: ‘tbl_next’ may be used uninitialized in
> > this function [-Werror=maybe-uninitialized]
> > if (!tbl[tbl_index].valid) {
> > ^
> > rte_lpm6.c:521:29: note: ‘tbl_next’ was declared here
> > struct rte_lpm6_tbl_entry *tbl_next;
> > ^~~~~~~~
> >
> > This is a false positive from gcc. Fix it by initializing tbl_next
> > to NULL.
>
> This is hard to trace, and it seems there is a way to have it, not sure
> practically possible:
>
> rte_lpm6_add_v1705
> add_step
> if (depth <= bits_covered) {
> ...
> return 0 <--- so tbl_next stays untouched.
> tbl = tbl_next
> add_step
> tbl[tbl_index]
>
>
> So same comment as previous, if there is a practically available path,
> this patch makes it harder to find by hiding compiler warning, so adding
> maintainer for decision.
>
>
+Cristian, who has more knowledge of this library than I.
I don't think there is an issue here, since there is an additional check
before the second and subsequent calls to add_step(). The condition
check on the loop in add_v1705 is:
"i < RTE_LPM6_IPV6_ADDR_SIZE && status == 1;"
The "return 0" sets status to 0, causing the loop to break, preventing
any more calls to "tbl = tbl_next".
Therefore I don't think this masks an issue, and the fix is ok.
In the absense of any other objections or comments on this from
Cristian:
Acked-by: Bruce Richardson <bruce.richard...@intel.com>
