While definitely not a prime example of StringRef usage, it is not strictly a bug either. Future calls of getopt will modify the value of optarg, but the actual string it points to (will have pointed to) remains unchanged as that is just some member of the initial argv array.
That said, I have no objections to making that a regular string, as it will avoid any doubts in the future. pl On 12 April 2017 at 23:43, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Wed, Apr 12, 2017 at 10:43 AM Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> What I now believe is happening is lldb-server is exiting for some reason >> and then the process just runs and still shows the output in LLDB because >> we hooked up the STDIO. I see lldb-server exits with an exit code of 0, but >> no command had been sent to terminate it. I will track that down. >> >> Also, log_channels in lldb-gdbserver.cpp is using a llvm::StringRef >> incorrectly: >> >> case 'c': // Log Channels >> if (optarg && optarg[0]) >> log_channels = StringRef(optarg); >> break; >> >> Bad! This is exactly when we shouldn't be using llvm::StringRef. optarg >> is a static variable and can change if there are any arguments after "-c >> <args>". >> > > Good catch, log_channels should definitely be a std::string here. > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
