Re: uninitialized variable in if_mue.c

2018-09-18 Thread Kevin Lo
On Tue, Sep 18, 2018 at 08:40:24AM +0100, Ricardo Mestre wrote: > > Ouch, of course! Still not enough caffeine in the system! > > Unfortunately I don't have such a card to test it, but this is the way it's > done > everywhere else, the writes are always done unconditionally and we just need >

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Mark Kettenis
> Date: Tue, 18 Sep 2018 07:55:43 +0100 > From: Ricardo Mestre > > Hi, > > In the case that a mue(4) device is put in promiscuous mode then hashtbl will > be used uninitialized a little bit down the road so set it 0 like it's done in > a lot of other devices. Coverity ID 1473316. > > OK? > >

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Ricardo Mestre
Ouch, of course! Still not enough caffeine in the system! Unfortunately I don't have such a card to test it, but this is the way it's done everywhere else, the writes are always done unconditionally and we just need to ensure that the hash table is initialized to 0 so I prefer to keep the

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Claudio Jeker
On Tue, Sep 18, 2018 at 07:55:43AM +0100, Ricardo Mestre wrote: > Hi, > > In the case that a mue(4) device is put in promiscuous mode then hashtbl will > be used uninitialized a little bit down the road so set it 0 like it's done in > a lot of other devices. Coverity ID 1473316. > > OK? Please

uninitialized variable in if_mue.c

2018-09-18 Thread Ricardo Mestre
Hi, In the case that a mue(4) device is put in promiscuous mode then hashtbl will be used uninitialized a little bit down the road so set it 0 like it's done in a lot of other devices. Coverity ID 1473316. OK? Index: if_mue.c ===