<div dir="ltr"><div class="gmail_extra">Hi Johannes,<br><br><div class="gmail_quote">On 9 November 2013 15:49, Johannes Schickel <span dir="ltr"><<a href="mailto:lordhoto@gmail.com" target="_blank">lordhoto@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 10/30/2013 12:24 PM, Eugene Sandulenko wrote:<br>
> On 30 October 2013 12:52, Willem Jan Palenstijn <<a href="mailto:wjp@usecode.org" target="_blank">wjp@usecode.org</a><br>
</div>> <mailto:<a href="mailto:wjp@usecode.org" target="_blank">wjp@usecode.org</a>>>wrote:<br>
<div>><br>
> In particular, blindly initializing variables in constructors<br>
> while they<br>
> _should_ already be initialized in some init() method just hides<br>
> potential bugs<br>
> in init() or missed calls to init(). On top of that, it makes<br>
> tools like<br>
> valgrind or better static analysis useless for finding and<br>
> catching any such bugs.<br>
><br>
><br>
> I agree, however I am the primarily reason for this email being sent.<br>
><br>
><br>
<br>
</div>I am bit confused about the recent commits 6491ad1cf9...38d02d1687<br>
(among others, but that's the biggest batch I've seen ;-)). I thought<br>
there was an agreement to Willem Jan's post stating that these<br>
initialization changes were not the best idea and thus we shouldn't do<br>
them. But maybe I didn't get this right?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Eugene</div><div><br></div><div> </div></div></div></div>