On Ubuntu 20.04, when building with clang -Werror -Wextra-semi-stmt
(which is not the default build configuration), the compiler reports:
../cil/src/cil_binary.c:4293:22: error: empty expression statement
has no effect; remove unnecessary ';' to silence this warning
[-Werror,-Wextra-semi-stmt]
mix(k->target_class);
^
../cil/src/cil_binary.c:4294:21: error: empty expression statement
has no effect; remove unnecessary ';' to silence this warning
[-Werror,-Wextra-semi-stmt]
mix(k->target_type);
^
../cil/src/cil_binary.c:4295:21: error: empty expression statement
has no effect; remove unnecessary ';' to silence this warning
[-Werror,-Wextra-semi-stmt]
mix(k->source_type);
^
../cil/src/cil_binary.c:4296:19: error: empty expression statement
has no effect; remove unnecessary ';' to silence this warning
[-Werror,-Wextra-semi-stmt]
mix(k->specified);
^
Use a do { ... } while (0) construction to silence this warning.
Moreover the same warning appears when using two semicolons to end a
statement. Remove such occurrences, like what was already done in commit
811185648a ("libsepol: drop repeated semicolons").
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
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>
Use codespell (https://github.com/codespell-project/codespell) in order
to find many common misspellings that are present in English texts.
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>
When write_binary_policy() fails to open the binary policy, it calls
sepol_handle_destroy(f.handle) but structure f has not been initialized
at this point. Use variable handle instead.
This issue has been found using clang's static analyzer.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
f.handle is never set in read_binary_policy() so there is no need to
call sepol_handle_destroy() on it. Moreover clang's static analyzer
warns about an uninitialized argument value in the first call.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
A build toolchain may override CPPFLAGS on the command line of "make".
Doing so currently breaks libsepol/tests compilation, as it requires
"-I../include/ -I$(CHECKPOLICY)" to be provided in gcc's arguments.
This completes commit 15f2740733 ("Makefiles: override *FLAGS and
*LIBS").
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
when building packages (e.g. for openSUSE Linux)
(random) filesystem order of input files
influences ordering of functions in the output,
thus without the patch, builds (in disposable VMs) would usually differ.
See https://reproducible-builds.org/ for why this matters.
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 running "make test" with the Address Sanitizer (by adding
-fsanitize=address to compiler flags), a lot of memory leaks are
reported from checkpolicy. Anyway some leaks come from the tests and it
seems cleaner to start fixing these ones.
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>
Even though g_b_role_2 is used both in
tests/policies/test-linker/small-base.conf and
tests/policies/test-linker/module1.conf, it seems to only exists in the
scope of the base policy.
This fixes the following failure of "make -C libsepol test":
./libsepol-tests
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
Suite: cond
Test: cond_expr_equal ...passed
Suite: linker
Test: linker_indexes ...passed
Test: linker_types ...passed
Test: linker_roles ...sym g_b_role_2 has 1 decls, 2 expected
FAILED
1. test-common.c:43 - scope->decl_ids_len == len
2. test-common.c:52 - found == 1
Test: linker_cond ...passed
Suite: expander
Test: expander_indexes ...passed
Test: expander_attr_mapping ...passed
Test: expander_role_mapping ...passed
Test: expander_user_mapping ...passed
Test: expander_alias ...passed
Suite: deps
Test: deps_modreq_global ...passed
Test: deps_modreq_opt ...passed
Suite: downgrade
Test: downgrade ...passed
Run Summary: Type Total Ran Passed Failed Inactive
suites 5 5 n/a 0 0
tests 13 13 12 1 0
asserts 1274 1274 1272 2 n/a
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
test-linker-roles.c: In function 'module_role_tests':
test-linker-roles.c:147:7: error: array subscript is above array bounds
[-Werror=array-bounds]
decls[2] = (test_find_decl_by_sym(base, SYM_TYPES,"tag_g_m2"))->decl_id;
^
Acked-by: Steve Lawrence <slawrence@tresys.com>
This test must have been disabled a very long time ago, before attributes were present in the kernel policy. Since the attributes are now present this unit test should be turned back on, unless I'm missing something pretty major (it looks reasonable and is successful when run).
Signed-off-by: Joshua Brindle <jbrindle@tresys.com>
