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 <r...@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 <ztur...@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@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
