<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 11/18/16 3:55 PM, Zachary Turner via lldb-dev wrote:<br>
    <blockquote
cite="mid:CAAErz9iK-p1eVZwV7Wz7O4JbASF+EpsHNnq1y5j2QsFrY+jFcw@mail.gmail.com"
      type="cite">
      <div dir="ltr">On line 708 of CommandObjectFrame.cpp, I'm looking
        at this code:
        <div><br>
        </div>
        <div>
          <div>options.SetRootValueObjectName(name_cstr);</div>
        </div>
        <div><br>
        </div>
        <div>This code occurs inside the else block of an if/else.
           name_cstr is declared prior to the if/else block and
          initialized to nullptr, but is only ever set to something
          other than nullptr in the if branch.</div>
        <div><br>
        </div>
        <div>So, this code is equivalent to</div>
        <div><br>
        </div>
        <div>options.SetRootValueObjectName(nullptr);  <br>
        </div>
        <div><br>
        </div>
        <div>Is this intended,</div>
      </div>
    </blockquote>
    Probably not<br>
    <blockquote
cite="mid:CAAErz9iK-p1eVZwV7Wz7O4JbASF+EpsHNnq1y5j2QsFrY+jFcw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div> and if not how would this bug manifest itself in terms of
          incorrect behavior?</div>
      </div>
    </blockquote>
    That I am not sure about.. I tried a couple obvious things, but I
    couldn't make them fail. It's possible that some arcane combination
    of options would do it. OTOH, my hunch is that we could simply fix
    the bug. Trying a patch of the form<br>
    <br>
    Index: source/Commands/CommandObjectFrame.cpp<br>
    ===================================================================<br>
    --- source/Commands/CommandObjectFrame.cpp    (revision 287375)<br>
    +++ source/Commands/CommandObjectFrame.cpp    (working copy)<br>
    @@ -704,7 +704,7 @@<br>
                       options.SetFormat(format);<br>
                       options.SetVariableFormatDisplayLanguage(<br>
                           valobj_sp->GetPreferredDisplayLanguage());<br>
    -                  options.SetRootValueObjectName(name_cstr);<br>
    +                  options.SetRootValueObjectName(var_sp ?
    var_sp->GetName().AsCString() : nullptr);<br>
                       valobj_sp->Dump(result.GetOutputStream(),
    options);<br>
                     }<br>
                   }<br>
    <br>
    is the first thing I would do. On the face of it, it looks correct
    behavior (the "root name" is the name of the variable being
    displayed). Still worth a test suite run of course - but if you run
    into any regressions due to the change, it's worth bringing them up.
    It's possible the test is testing the wrong behavior and we found
    our smoking gun in terms of actual incorrect behavior.<br>
    <blockquote
cite="mid:CAAErz9iK-p1eVZwV7Wz7O4JbASF+EpsHNnq1y5j2QsFrY+jFcw@mail.gmail.com"
      type="cite">
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>