[lldb-dev] raw c strings in lldb

[Zachary Turner]

Ahh, I just noticed you mentioned that in your message.  Sorry for the
noise (and the additional noise from this response :-/)

On Wed Feb 11 2015 at 10:28:30 AM Zachary Turner <zturner at google.com> wrote:

> Also:
>
> Find all "using namespace llvm;", Subfolders, Find Results 1,
> "d:\src\llvm", "*.cpp"
> ...
> Matching lines: 1418    Matching files: 1392    Total files searched: 5811
>
> So "using namespace llvm" is certainly not without precedent either.
>
> On Wed Feb 11 2015 at 10:26:21 AM Reid Kleckner <rnk at google.com> wrote:
>
>> 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.
>>
>> On Wed, Feb 11, 2015 at 10:18 AM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> 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?
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150211/f626a726/attachment.html>