[Scummvm-devel] coverity
Eugene Sandulenko
sev.mail at gmail.com
Sat Nov 9 20:41:07 CET 2013
Hi Johannes,
On 9 November 2013 15:49, Johannes Schickel <lordhoto at gmail.com> wrote:
> On 10/30/2013 12:24 PM, Eugene Sandulenko wrote:
> > On 30 October 2013 12:52, Willem Jan Palenstijn <wjp at usecode.org
> > <mailto:wjp at usecode.org>>wrote:
> >
> > In particular, blindly initializing variables in constructors
> > while they
> > _should_ already be initialized in some init() method just hides
> > potential bugs
> > in init() or missed calls to init(). On top of that, it makes
> > tools like
> > valgrind or better static analysis useless for finding and
> > catching any such bugs.
> >
> >
> > I agree, however I am the primarily reason for this email being sent.
> >
> >
>
> I am bit confused about the recent commits 6491ad1cf9...38d02d1687
> (among others, but that's the biggest batch I've seen ;-)). I thought
> there was an agreement to Willem Jan's post stating that these
> initialization changes were not the best idea and thus we shouldn't do
> them. But maybe I didn't get this right?
>
There are several types of unitialized variables. One big chunk is
basically a false positive since we use Engine::init() methods, and then
there are tons of really uninitalized stuff. I am really glad that coverity
gives me possibility to fix those obscure bugs and point out variables
which are initialized with garbage on MacOS and Linux, but work fine on
Windows.
I agree with Willem that it is not really good to address first part in
many cases, but not in all. If you take a look, you will see, that in these
cases the variables are initialized much deeper that ::init(), and some
further refactoring could potentially lead to unstable behavior. So in my
opinion in these cases it is cheaper and better to plug the hole altogether.
Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20131109/ad65ed9e/attachment.html>
More information about the Scummvm-devel
mailing list