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>
- Python 2.7 is planned to be the last of the 2.x releases
- It's generally advised to use Python 3
- Majority of python/ scripts are already switched python3
- Users with python 2 only can still use:
$ make PYTHON=/usr/bin/python ....
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
- new release files are created in release/$RELEASE_TAG
- download links refers to new release assets
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Set-up environment variables in order to use DESTDIR in Python, Ruby,
etc. This makes testing Python scripts easier.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When running flake8 on a directory, it does not analyze files without an
extension, like semanage_migrate_store, mlscolor-test, etc. Use grep to
find files with a Python shebang and build a list which is then given to
flake8.
This commit is possible now that some clean-up patches have been
applied, such as commit 69c56bd2f6 ("python/chcat: improve the code
readability") and b7227aaec1 ("mcstrans: fix Python linter warnings on
test scripts") and 3cb974d2d2 ("semanage_migrate_store: fix many
Python linter warnings").
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
PLY (Python Lex-Yacc) 3.11 has been released in February 2018:
- http://www.dabeaz.com/ply/index.html
- https://github.com/dabeaz/ply/releases/tag/3.11
Copy lex.py and yacc.py from this new release.
This fixes the following warning from "make test":
python run-tests.py
../src/./sepolgen/lex.py:634: DeprecationWarning: Using or importing
the ABCs from 'collections' instead of from 'collections.abc' is
deprecated, and in 3.8 it will stop working
if isinstance(t, collections.Callable):
(Python 3.3 moved collections.Callable to collections.abc.Callable)
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Python does not need to end a statement with a semicolon. Doing this
gets reported by linters such as flake8 ("E703 statement ends with a
semicolon").
Remove such semicolons in the code and enable this warning in
scripts/run-flake8.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
flake8 is a Python linter which is able to detect issues in Python code
(syntax errors, undefined variables, etc.). It has been used to find
bugs in the project. In order to prevent the introduction of new bugs
which can be detected by it, add a script which runs it and use it in
Travis-CI.
flake8 can be used to detect code which is not written according to PEP8
style guide (which forbids whitespaces in some places, enforces the use
of space-indenting, specifies how many blank lines are used between
functions, etc.). As SELinux code does not follow this style guide,
scripts/run-flake8 disables many warnings related to this when running
the linter.
In order to silence flake8 warnings, the Python code can also be
modified. However fixing every "do not use bare 'except'" in the project
needs to be done carefully and takes much time.
This is why the warnings which are disabled have been ordered in three
lists:
* The warnings which can be activated in a not-so-distant future after
the code has been modified.
* The warnings related to PEP8 which cannot be activated without a major
cleaning work of the codebase (for example to modify white spaces)
* The warnings which are introduced by code generated by SWIG 3.0.12,
which would require patches in SWIG in order to be activated (there
is right now only one such warning).
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Using clang's static analyzer is as simple as running "scan-build make",
but in order to obtain clean and reproducible results, the build
environment has to be cleaned beforehand ("make clean distclean").
Moreover the project requires running "make install" before "make test"
in order to install the dependencies needed for the tests, and running
these tests with the newly-built libraries requires a specific
LD_LIBRARY_PATH. This new script takes care of setting up everything
which is needed.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
make-update script is for generating an update for an existing release,
e.g. for a bug fix update.
release script is for generating a new release.
Per-package tagging may fail on the release script if the version
has not changed; this is harmless.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Tag the release before generating it, and automatically generate
a template for use in updating the wiki page. Also, make the
output directory unique to each release, delete any prior contents,
and tell the user where to find it.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
