<div dir="ltr">I'd also point out that if you hate writing "llvm::" or using decls everywhere, you can import StringRef into the lldb namespace. Clang does this in include/clang/Basic/LLVM.h for StringRef and other common classes.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 10:18 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@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 dir="ltr">A <a href="http://reviews.llvm.org/D7553" target="_blank">patch is up</a> which fixes a number of issues with strings not being null terminated in LLDB.  The issues and error-proneness of using raw c strings is well documented and understood, so I would like to propose banning them in LLDB for new code [1].<div><br></div><div>I realize that's a tall order, and I don't expect all the occurrences of them to go away overnight, but issues related to strings have been popping up over and over again, and it would be nice if we could deal with more interesting problems.</div><div><br></div><div>LLVM has a very robust string manipulation library, and while it's not perfect, it would have prevented almost all of these issues from ever happening in the first place.  Here is a quick summary of common C string types / operations and their corresponding LLVM equivalents:</div><div><br></div><div><div><div><span style="line-height:19.7999992370605px">Types:</span></div><div><span style="line-height:19.7999992370605px">char stack_buffer[n];        // Use llvm::SmallString<n>.</span></div><div><span style="line-height:19.7999992370605px">const char* foo;             // Use llvm::StringRef foo.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">Passing arguments;</span></div><div><span style="line-height:19.7999992370605px">void foo(char *, int len);   // Use void foo(llvm::SmallVectorImpl<char> &buf);</span></div><div><span style="line-height:19.7999992370605px">void foo(const char * foo);  // Use void foo(llvm::StringRef foo);</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">Operations:</span></div><div><span style="line-height:19.7999992370605px">strcpy, strncpy, etc         // Use member functions of SmallString / StringRef</span></div><div><span style="line-height:19.7999992370605px">sprintf, snprintf, etc       // Use llvm::raw_ostream</span></div></div></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">We can fix existing occurrences gradually / as time permits, but I would prefer to see a trend towards new code using llvm's string classes and formatting library, and when you are touching a piece of code that is messing with raw c-strings, that's a perfect time to change that code to migrate to LLVM strings.</span><br></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">[1] There are a couple of places where we can't ban them entirely.  This relates to the public API (i.e. can't change an existing signature), and va_args off the top of my head.  The va_args stuff though, if generally useful, if stuff we can sink into LLVM, there's nothing debuggery about formatting strings.</span></div><div><br></div><div>Thoughts?  Suggestions?  Comments?</div></div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br></div>