Ron et everyone else,
Coverity lets you 'own' bugs so it's clear who's working on what. Also,
we can flag issues als false positives.
Cheers,
M
On 01/26/2015 10:03 AM, Ron Economos wrote:
> After looking at the code a little more, Coverity is correct about
> CID 1267227. Not sure why it doesn't
After looking at the code a little more, Coverity is correct about
CID 1267227. Not sure why it doesn't complain about the previous
line. The original code had I and J passed in as parameters, and
setting the private variables was necessary. In the ATSC version,
I and J are fixed, so I removed the
I can address the two issues in gr-dtv.
CID 1267227 seems spurious. Coverity doesn't complain about the previous
line,
even though it's doing exactly the same operation. Also, the code executes
properly, so there's no doubt that this->J is being set.
Of course, the this-> business is a bit of
FYI.
Forwarded Message
Subject: New Defects reported by Coverity Scan for GNURadio
Date: Sun, 25 Jan 2015 23:13:10 -0800
From: scan-ad...@coverity.com
To: phi...@balister.org
Hi,
Please find the latest report on new defect(s) introduced to GNURadio
found with Coverity Scan.
Fix em fast! (Or figure out they are false alarms).
Philip
Forwarded Message
Subject: New Defects reported by Coverity Scan for GNURadio
Date: Mon, 22 Sep 2014 00:01:27 -0700
From: scan-ad...@coverity.com
Hi,
Please find the latest report on new defect(s) introduced to GNUR
On 03/03/2014 05:00 PM, Tom Rondeau wrote:
> On Mon, Mar 3, 2014 at 4:58 PM, Philip Balister wrote:
>> The latest Coverity scan showed these new items. We should probably
>> double check them. The Null dereference is likely related to the order
>> in which some class methods get called.
>>
>> The
On Mon, Mar 3, 2014 at 4:58 PM, Philip Balister wrote:
> The latest Coverity scan showed these new items. We should probably
> double check them. The Null dereference is likely related to the order
> in which some class methods get called.
>
> The compare against zero of an unsigned number should
The latest Coverity scan showed these new items. We should probably
double check them. The Null dereference is likely related to the order
in which some class methods get called.
The compare against zero of an unsigned number should be checked to make
sure that is what was really meant.
Philip
