[PATCH] misc-uninitialized-field

Jonathan B Coe jon at jbcoe.net
Tue Jun 23 11:02:05 PDT 2015


================
Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:56
@@ +55,3 @@
+    
+    for (clang::CXXCtorInitializer *Init : Ctor->inits()) {
+      const FieldDecl *MemberField = Init->getMember();
----------------
alexfh wrote:
> jbcoe wrote:
> > alexfh wrote:
> > > jbcoe wrote:
> > > > alexfh wrote:
> > > > > What about fields initialized in the constructor body?
> > > > My check does not take that into account. I think it's hard to do in general so I decided to let the user decide to ignore the check and proposed change. I presume that the optimiser is smart enough to do the right thing if a variable is obviously initialized in the constructor body and constructor field initializers.
> > > > 
> > > What about this?
> > I got confused by comment submission. Comment added.
> This decision needs to be documented in the class comment. And it may make sense to look at the number of false positives resulting from specifically this case and estimate how many of those could be avoided by just looking at which fields are assigned inside the constructor body.
I'll look into this.

================
Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:70
@@ +69,3 @@
+
+    std::stringstream ss;
+    for (const auto MemberField : MemberFields) 
----------------
alexfh wrote:
> jbcoe wrote:
> > alexfh wrote:
> > > alexfh wrote:
> > > > In LLVM code, `llvm::raw_string_ostream` or `llvm::raw_svector_ostream` are used instead of `std::stringstream`.
> > > Did you miss this comment?
> > I'm using a string instead. llvm::raw_string_ostream takes a string ref as a constuctor argument and the code is simpler if I just use the string directly.
> `llvm::raw_string_ostream` is preferred for efficiency reasons. Your current version creates temporary strings on each iteration. You could prevent this by appending the two strings separately or by using `raw_string_stream`. The latter seems like a more elegant solution to me.
agreed.

http://reviews.llvm.org/D10553

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list