<div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 16, 2012 at 3:10 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Jul 16, 2012 at 6:02 AM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div>On Fri, Jul 13, 2012 at 3:06 PM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Alexander,<br>
<div>> Initializers for some fields were missing in Option::Option<br>
<br>
</div>did it matter?  If so, please add a testcase.  If not, why this change?<br></blockquote></div><div>This did matter. It caused random crashes in case cl::opt was a member of non-POD class.</div></div></div></blockquote>

<div><br></div></div><div>Hold on, a *member*? 'cl::opt' objects are supposed to be globals, not members.</div></div></div></blockquote><div>We need it as a member to make a class which handles a common subset of command-line options for several clang tools. In a close future we'll need a control on which options should be enabled and which not. So we can't do it with global variables. Why can't we use it as a member?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div>Also, please get LLVM patches reviewed on llvm-commits, not cfe-commits.</div>
</div></div></blockquote><div>I didn't send this patch for a review, as I considered it to be an obvious bug fix. Sorry, if I was wrong.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div> And I always considered it obvious that uninitialized data is bad. Don't you think so?</div>

</div></div></blockquote><div><br></div></div><div>No, uninitialized data is fine. It's *using* uninitialized data that is bad, and we have tools such as valgrind to detect those bugs. If you blindly initialize data, it prevents tools like valgrind from finding real bugs in code where data was read inappropriately.</div>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div>A test case which fails under valgrind is the classic way of exercising bugs here if this is a bug.</div>
</div></div>
</blockquote></div><div>I've found this bug with a help of valgrind, but I'm not sure how to write tests that should run using valgrind. Can you point me to an example?</div><div><br></div>-- 
</div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Alexander</div>