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 <ztur...@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 <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
