search

jiangwenhan / googletest

Automatically exported from code.google.com/p/googletest
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

static analysis of GTEST_TEST_BOOLEAN_ is not possible #417

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Because the boolean expression is passed to the AssertionResult it is 
impossible for static analysis to understand that the if branch is guaranteed 
to be entered if the expression is true. For clang static analyzer the 
following patch makes it understand the connection and prevents false positives 
in tests.

@@ -1173,6 +1173,7 @@ class NativeArray {
 // Implements Boolean test assertions such as EXPECT_TRUE. expression can be
 // either a boolean expression or an AssertionResult. text is a textual
 // represenation of expression as it was passed into the EXPECT_TRUE.
+#ifndef __clang_analyzer__
 #define GTEST_TEST_BOOLEAN_(expression, text, actual, expected, fail) \
   GTEST_AMBIGUOUS_ELSE_BLOCKER_ \
   if (const ::testing::AssertionResult gtest_ar_ = \
@@ -1181,6 +1182,15 @@ class NativeArray {
   else \
     fail(::testing::internal::GetBoolAssertionFailureMessage(\
         gtest_ar_, text, #actual, #expected).c_str())
+#else
+#define GTEST_TEST_BOOLEAN_(expression, text, actual, expected, fail) \
+  GTEST_AMBIGUOUS_ELSE_BLOCKER_ \
+  if (bool gtest_r_ = expression)      \
+    ; \
+  else \
+    fail(::testing::internal::GetBoolAssertionFailureMessage(\
+         ::testing::AssertionResult(gtest_r_), text, #actual, 
#expected).c_str())
+#endif

 #define GTEST_TEST_NO_FATAL_FAILURE_(statement, fail) \
   GTEST_AMBIGUOUS_ELSE_BLOCKER_ \
diff --git a/src/gromacs/selection/tests/selectionoption.cpp 
b/src/gromacs/selection/tests/selectionoption.cpp

Original issue reported on code.google.com by rol...@rschulz.eu on 29 Aug 2012 at 3:31

GoogleCodeExporter commented 9 years ago 
While it's unfortunate that Clang static analyzer fails to recognize this 
pattern, the proposed patch is a bad solution. It makes Clang analyze some 
"nice" code instead of the code that is actually going to be executed. The real 
solution is in improving Clang's static analyzer - you should file a bug 
against it citing this pattern.

Original comment by vladlosev on 4 Sep 2012 at 11:07