[lldb-dev] raw c strings in lldb

[Zachary Turner]

A patch is up <http://reviews.llvm.org/D7553> 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].

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.

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:

Types:
char stack_buffer[n];        // Use llvm::SmallString<n>.
const char* foo;             // Use llvm::StringRef foo.

Passing arguments;
void foo(char *, int len);   // Use void foo(llvm::SmallVectorImpl<char>
&buf);
void foo(const char * foo);  // Use void foo(llvm::StringRef foo);

Operations:
strcpy, strncpy, etc         // Use member functions of SmallString /
StringRef
sprintf, snprintf, etc       // Use llvm::raw_ostream

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.

[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.

Thoughts?  Suggestions?  Comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150211/7cad5522/attachment.html>