kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 11/07/2015 11:52 AM, jp charras wrote:
> Le 06/11/2015 19:35, Wayne Stambaugh a écrit :
>> On 11/6/2015 12:04 PM, Mark Roszko wrote:
>>> One thing I didn't think was fixed yet was a null dereference
>>> introduced with the clipper library upgrade. jp fixed the
>>> uninitialized warnings but theres still a explicit null deref in a
>>> loop condition. CID 132144. What does it impact? No clue.
>>
>> There should be at least an assertion for debug builds and a skip branch
>> on release builds.  A null pointer may never occur but I prefer
>> defensive programming whenever possible.  wxCHECK_MSG() and
>> wxCHECK2_MSG() can be useful in this case.
> 
> I had a look at this warning
> For me, this is a false positive.

As long as there is no possible way for this pointer to be null at
runtime then that's fine.  Please mark the Coverity warning as false
positive with a short description as to why it is a false positive.

> 
>>
>>>
>>> And speaking of pns, there is still CID 106401 where
>>> PNS_MEANDERED_LINE::MeanderSegment can memory leak.
>>>
>>
>> Tom or Orson can you please take a look at this?  I typically use an
>> auto_ptr() and auto_ptr::release() in this case just to be safe.  It
>> also covers the case when a exception occurs somewhere in the middle of
>> your code.  If this can never occur because of the design of the code
>> leading up that that point, you may want to tag the Coverity error as
>> such.  However, it does look to me as though you can get to that point
>> in which case you have a memory leak.  Given that MeanderSegment is
>> adding new segments the memory leak could be substantial over long
>> editing sessions.
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
>