kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Den 31/03/2015 13.29 skrev "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>:
>
> I've just been going through the Coverity thing during a break at work
> and tagged a few things ready to fix at home. The second I noticed is
> because we use delete on a member variable pointer without
> re-assignment.
>
> I think it would be good policy to say unless the scope of the pointer
> variable is the local code block, delete must be immediately followed
> by a NULL assignment. i.e. from what I'm looking at now in the
> vrml_v2_modelparser.cpp:241 or :263
>
>     delete m_model;
>
> should really be:
>
>     delete m_model;
>     m_model = NULL;
>
> Other functions (namely read_DEF) make assignment from m_model. It's
> too complicated to try and rely on knowing the logical order of
> functions in a file format parser to guarantee that it won't break. At
> least if the assignment from m_model assigns NULL, debugging is
> reasonably sane.
>
> As an aside, I came across code ( pcbnew/eagle_plugin.cpp:1406 :1504,
> etc ) in which the coding style policy 4.2.3 has been applied to else
> if clauses. Is that intended? There's both types in that file. I was
> going to do some tidying as I went along fixing Coverity items and
> don't know which to go for. The coding style policy 4.7 has an example
> where there's no blank line above them for reference...

I dont have the file at hand now, not as I see it, the brace rule shouls
override the emtpy line before if rule.  Wayne, please confirm if this is
how it is supposed to be read. FYI I have an upcomming patch that will fix
som import issues in the eagle importer plugin.
>
> Best Regards,
>
> Brian.
>
>
>
> On 30 March 2015 at 19:15, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> > Now that we are in feature freeze, the next big task is to fix all of
> > our critical and high importance bugs in the bug tracker.  To me,
> > critical bugs are anything that causes a crash and/or data
> > loss/curruption and high importance bugs are memory leaks.  These must
> > be fixed before release.  Everything else is medium, low, or wishlist
> > and do not need to be fixed for the stable release.  It doesn't look
> > like there are many critical/high importance bugs that are not tagged as
> > fix released.  However, I'm not sure all of the bugs that are
> > critical/high importance have been tagged correctly so we need to make
> > sure nothing has fallen through the cracks.  We also need to tagged any
> > of the these bugs as fix committed if they have been fixed.
> >
> > All Coverity scan errors with a high impact need to be address.  If they
> > are false positives, please mark them as such.  I still see some
> > resource leaks in there so those should be given priority.  All other
> > errors can be fixed when convenient.
> >
> > I would like to have at a minimum of one month after the last of the
> > these issues is resolved so users can test to make sure there are no
> > other issues lurking just beneath the surface.
> >
> > Thank you everyone for your hard work.  Hopefully we can make the stable
> > release happen sometime around the middle of the year.
> >
> > Cheers,
> >
> > Wayne
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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