On 11/25/19 3:40 AM, Erik Skultety wrote:
> On Mon, Nov 25, 2019 at 09:30:26AM +0100, Jiri Denemark wrote:
>> On Fri, Nov 22, 2019 at 17:09:00 +0100, Erik Skultety wrote:
>>> Since we know for sure that the @bandwidth parameter is properly handled
>>> in networkCheckBandwidth (@ifaceBand), it ca
On Mon, Nov 25, 2019 at 09:30:26AM +0100, Jiri Denemark wrote:
> On Fri, Nov 22, 2019 at 17:09:00 +0100, Erik Skultety wrote:
> > Since we know for sure that the @bandwidth parameter is properly handled
> > in networkCheckBandwidth (@ifaceBand), it cannot ever be NULL, but
> > coverity doesn't see
On Fri, Nov 22, 2019 at 17:09:00 +0100, Erik Skultety wrote:
> Since we know for sure that the @bandwidth parameter is properly handled
> in networkCheckBandwidth (@ifaceBand), it cannot ever be NULL, but
> coverity doesn't see this fact. In order to prevent coverity from
> reporting a false positi
On 11/22/19 5:09 PM, Erik Skultety wrote:
Since we know for sure that the @bandwidth parameter is properly handled
in networkCheckBandwidth (@ifaceBand), it cannot ever be NULL, but
coverity doesn't see this fact. In order to prevent coverity from
reporting a false positive here, drop ATTRIBUTE_U
On 11/22/19 1:09 PM, Erik Skultety wrote:
Since we know for sure that the @bandwidth parameter is properly handled
in networkCheckBandwidth (@ifaceBand), it cannot ever be NULL, but
coverity doesn't see this fact. In order to prevent coverity from
reporting a false positive here, drop ATTRIBUT
Since we know for sure that the @bandwidth parameter is properly handled
in networkCheckBandwidth (@ifaceBand), it cannot ever be NULL, but
coverity doesn't see this fact. In order to prevent coverity from
reporting a false positive here, drop ATTRIBUTE_UNUSED for this specific
argument - virNetDev
