[llvm-commits] [llvm] r160170 - /llvm/trunk/include/llvm/Support/CommandLine.h

[Alexander Kornienko]

On Mon, Jul 16, 2012 at 3:10 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Mon, Jul 16, 2012 at 6:02 AM, Alexander Kornienko <alexfh at google.com>wrote:
>
>>
>> On Fri, Jul 13, 2012 at 3:06 PM, Duncan Sands <baldrick at free.fr> wrote:
>>
>>> Hi Alexander,
>>> > Initializers for some fields were missing in Option::Option
>>>
>>> did it matter?  If so, please add a testcase.  If not, why this change?
>>>
>> This did matter. It caused random crashes in case cl::opt was a member of
>> non-POD class.
>>
>
> Hold on, a *member*? 'cl::opt' objects are supposed to be globals, not
> members.
>
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?


> Also, please get LLVM patches reviewed on llvm-commits, not cfe-commits.
>
I didn't send this patch for a review, as I considered it to be an obvious
bug fix. Sorry, if I was wrong.

 And I always considered it obvious that uninitialized data is bad. Don't
>> you think so?
>>
>
> 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.
>
A test case which fails under valgrind is the classic way of exercising
> bugs here if this is a bug.
>
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?

--
Regards,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120716/a83f66ce/attachment.html>