Avoid memory leakages in the fc_sort executable (now passes
all valgrind AND Clang static analyzer tests fine).
Some NULL pointer checks with or without associated error
reporting.
Some white space and comment formatting fixes.
Optimization: avoid unnecessary operations (unnecessary
memory allocation/deallocation and list copying).
Reverts 7821eb6f37 as such
trick is no longer needed, given that all memory leakages
have now been fixed.
This is the sixth version of this patch. Please do not use
the first version as it introduces a serious bug.
For reference, the original issue reported by the Cland
static analyzer is as follows:
support/fc_sort.c:494:6: warning: Potential leak of memory
pointed to by 'head'
malloc(sizeof(file_context_bucket_t));
Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
Acked-by: William Roberts <william.c.roberts@intel.com>
Using the LLVM static analyzer, we get a warning about leaked memory
pointed by bcurrent. Since the warning happens within "main" and we
don't care about deallocating the memory and just call "exit" which
gets rid of the warning.
Fix a "-Werror=implicit-fallthrough" compiler warning/error on
the switch statement.
This third version (v3) fixes a bug introduced in the first
version and improves the style over the second version.
Signed-off-by: Guido Trentalancia <guido at trentalancia.com>
When working on fc_sort to try to understand why using /usr/s?bin/... file
contexts has been reported not to work properly [1], I found it frustrating not
to be able to do "tmp/fc_sort my_filecontexts.fc" and see the result printed on
the screen. This patch implements this behavior by making optional the second
argument of fc_sort.
[1] commit 36e2216f8 of contrib repository,
http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=commit;h=36e2216f82192660d063012e69281f27ba20864b
When running fc_sort on an empty context file, this program uses uninitialized
pointers when accessing to the elements of a list. On my system, it goes in a
very long loop (maybe infinite) because uninitialized fields in malloc'ed
structures happen to contain valid pointers in the heap.
This patch fixes this bug by initializing ->next and ->data fields before they
may be read.
William Roberts
Guido Trentalancia
Luis A. Lozano
Guido Trentalancia
Rahul Chaudhry
Nicolas Iooss
Chris PeBenito