[PATCH] [Clang Static Analyzer] Bug identification

Babati Bence bence.babati at ericsson.com
Wed Jun 10 06:08:03 PDT 2015

> I have the impression that if there is copy pasted code in a function and there are warnings then the hash will be the same. I don't know if this would be a problem.. but is that true?

You are right: when a code is copy pasted within the same function (which implies that within the same file), the bug ids will be the same. We think that, having the same bug id inside a function in same rare cases is better than a too fragile bug id.

If we distinguish somehow between the two errors in this scenario, that makes the bug id too fragile (change almost every time, the function body is edited). In case you have an idea that can generate different bug ids for this case but not too fragile, please let us know.

Comment at: include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:78
@@ -77,2 +77,3 @@
   std::string Description;
+  std::string HashField;
   PathDiagnosticLocation Location;
danielmarjamaki wrote:
> I wonder if this needs to be a std::string.. the size of a hash is known isnt it.
The HashField does not contains the hash itself but an arbitrary string generated by the checker to distinguish reports.  This is the optional extra field in the description. This string is added to the input of the hash function. 

Comment at: lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:430
@@ +429,3 @@
+                                          StringRef HashField, const Decl *D) {
+  static const std::string Delimeter = "$";
danielmarjamaki wrote:
> It seems to me that this can be a char. Is std::string necessary or was it chosen for safety?
Twine does not support appending a char, so I changed the delimiter to be a StringRef. The size of a StringRef is also smaller than a std::string. Thank you for this suggestion.



More information about the cfe-commits mailing list