[lldb-dev] raw c strings in lldb

[Zachary Turner]

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/90656551/attachment.html>