Several static analyzers (clang's one, Facebook Infer, etc.) warn about
NULL pointer dereferences after a call to CU_ASSERT_PTR_NOT_NULL_FATAL()
in the test code written using CUnit framework. This is because this
CUnit macro is too complex for them to understand that the pointer
cannot be NULL: it is translated to a call to CU_assertImplementation()
with an argument as TRUE in order to mean that the call is fatal if the
asserted condition failed (cf.
http://cunit.sourceforge.net/doxdocs/group__Framework.html).
A possible solution could consist in replacing the
CU_ASSERT_..._FATAL() calls by assert() ones, as most static analyzers
know about assert(). Nevertheless this seems to go against CUnit's API.
An alternative solution consists in overriding CU_ASSERT_..._FATAL()
macros in order to expand to assert() after a call to the matching
CU_ASSERT_...() non-fatal macro. This appears to work fine and to remove
many false-positive warnings from various static analyzers.
As this substitution should only occur when using static analyzer, put
it under #ifdef __CHECKER__, which is the macro used by sparse when
analyzing the Linux kernel.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In test_attr_types, the pointer decl is allowed to be NULL in the
beginning, but is dereferenced to produce a helpful message right before
a CU_ASSERT_FATAL. Make this derefence not happen if the pointer is
NULL.
This issue has been found using clang's static analyzer.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Most of the users of ebitmap_for_each_bit() macro only care for the set
bits, so introduce a new ebitmap_for_each_positive_bit() macro that
skips the unset bits. Replace uses of ebitmap_for_each_bit() with the
new macro where appropriate.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Since fd9e5ef7b7 ("libsepol: use constant keys in hashtab functions")
it is possible to call hashtab_search() with a const char* key value.
Doing so fixes compiler warnings about non-const char* string literals
(-Wwrite-strings flag).
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When compiling libsepol tests, clang complains about some uninitialized
variables:
test-common.c:171:14: error: variable 'my_primary' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
} else if (my_flavor == TYPE_ALIAS) {
^~~~~~~~~~~~~~~~~~~~~~~
test-common.c:179:30: note: uninitialized use occurs here
CU_ASSERT(type->primary == my_primary);
^~~~~~~~~~
/usr/include/CUnit/CUnit.h:123:30: note: expanded from macro
'CU_ASSERT'
{ CU_assertImplementation((value), __LINE__, #value, __FILE__, "", CU_...
^
test-common.c:171:10: note: remove the 'if' if its condition is
always true
} else if (my_flavor == TYPE_ALIAS) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-common.c:153:25: note: initialize the variable 'my_primary' to
silence this warning
unsigned int my_primary, my_flavor, my_value;
^
= 0
test-common.c:171:14: error: variable 'my_value' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
} else if (my_flavor == TYPE_ALIAS) {
^~~~~~~~~~~~~~~~~~~~~~~
test-common.c:181:30: note: uninitialized use occurs here
CU_ASSERT(type->s.value == my_value);
^~~~~~~~
/usr/include/CUnit/CUnit.h:123:30: note: expanded from macro
'CU_ASSERT'
{ CU_assertImplementation((value), __LINE__, #value, __FILE__, "", CU_...
^
test-common.c:171:10: note: remove the 'if' if its condition is
always true
} else if (my_flavor == TYPE_ALIAS) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-common.c:153:46: note: initialize the variable 'my_value' to
silence this warning
unsigned int my_primary, my_flavor, my_value;
^
= 0
This is because the call to CU_FAIL("not an alias") is not fatal in
test_alias_datum(), and variables my_primary and my_value are indeed
used uninitialized in a CU_ASSERT statement later.
Silent the warning by moving the elseif condition to a CU_ASSERT
statement which replaces the CU_FAIL.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
