From scan-build w/ clang-16.0.0_pre20230107:
```
../src/librc/librc.c:759:14: warning: Potential leak of memory pointed to by 'init' [unix.Malloc]
return false;
^~~~~
```
It's already initialised to false at the start and it's clear when reading
what the flow is.
While at it, fix some indentation and adjust whitespace to make more readable.
These become fine with C23 because () starts to mean (void) then, but for
previous language versions, it's deprecated, and it causes an annoying
warning when building with Clang by default.
Plus, GCC lacks specific flags to trigger what C23 *does* ban, so a lot
of people are going around building with -Wstrict-prototypes, so let's
just fix this to be consistent with the rest of the codebase anyway
to fend off false positive reports.
Despite this being a 'deptree', it's actually
xmalloc'd in the same function (rc_deptree_update),
and so should be free'd, not rc_deptree_free'd,
as rc_deptree_load* wasn't used to allocate it.
```
[71/213] Compiling C object src/librc/librc.so.1.p/librc-depend.c.o
../src/librc/librc-depend.c: In function ‘rc_deptree_update’:
../src/librc/librc-depend.c:1077:9: warning: ‘rc_deptree_free’ called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
1077 | rc_deptree_free(deptree);
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/shared/misc.h:29,
from ../src/librc/librc.h:57,
from ../src/librc/librc-depend.c:21:
In function ‘xmalloc’,
inlined from ‘rc_deptree_update’ at ../src/librc/librc-depend.c:775:12:
../src/shared/helpers.h:64:23: note: returned from ‘malloc’
64 | void *value = malloc(size);
| ^~~~~~~~~~~~
```
This fixes#563.
```
=================================================================
==22862==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f1fd5b12cb7 in __interceptor_malloc /usr/src/debug/sys-devel/gcc-11.2.1_p20220312/gcc-11-20220312/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x55556abecea7 in xmalloc ../src/includes/helpers.h:64
#2 0x55556abecea7 in xasprintf ../src/includes/helpers.h:149
#3 0x55556abeb6fb in do_check ../src/rc/checkpath.c:206
#4 0x55556abeb6fb in main ../src/rc/checkpath.c:443
#5 0x7f1fd58576cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 4096 byte(s) leaked in 1 allocation(s).
```
Signed-off-by: Sam James <sam@gentoo.org>
```
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f49539534a7 in __interceptor_strdup /usr/src/debug/sys-devel/gcc-11.2.1_p20220312/gcc-11-20220312/libsanitizer/asan/asan_interceptors.cpp:454
#1 0x55d76fa66867 in xstrdup ../src/includes/helpers.h:91
#2 0x55d76fa66867 in get_dirfd ../src/rc/checkpath.c:111
#3 0x55d76fa66867 in do_check ../src/rc/checkpath.c:206
#4 0x55d76fa66867 in main ../src/rc/checkpath.c:442
#5 0x7f49536f06cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Sam James <sam@gentoo.org>
(This is analogous to the rc_stringlist change.)
This gives a hint to the compiler that allocations (return values)
from this function should be paired with a corresponding dealloc/free
function.
Signed-off-by: Sam James <sam@gentoo.org>
This gives a hint to the compiler that allocations (return values)
from this function should be paired with a corresponding dealloc/free
function
In this case, it means that every rc_stringlist that rc_stringlist_new()
returns should eventually be freed by calling rc_stringlist_free(ptr)
where ptr is the relevant rc_stringlist.
We have to add a test for this into the build system
because only GCC supports this for now. In future, we might
be able to use meson's has_function_attribute (it does support
'malloc', just not AFAICT 'malloc with arguments').
Signed-off-by: Sam James <sam@gentoo.org>
'services' is still referenced by the list
which gets returned. We can't free it.
Thanks to GCC 11's -fanalyzer.
Signed-off-by: Sam James <sam@gentoo.org>
Seen on running rc-status.
```
=================================================================
==14636==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 72 byte(s) in 3 object(s) allocated from:
#0 0x7f443412dcb7 in __interceptor_malloc /usr/src/debug/sys-devel/gcc-11.2.1_p20220312/gcc-11-20220312/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f443400c727 in xmalloc ../src/includes/helpers.h:64
#2 0x7f443400d1f4 in rc_stringlist_add ../src/librc/librc-stringlist.c:32
#3 0x7f4433fecc34 in get_runlevel_chain ../src/librc/librc.c:390
#4 0x7f4433fedc00 in rc_runlevel_stacks ../src/librc/librc.c:519
#5 0x7f4433ff1d8e in rc_services_in_runlevel_stacked ../src/librc/librc.c:976
#6 0x55be0e8f9517 in main ../src/rc/rc-status.c:407
#7 0x7f44334736cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Sam James <sam@gentoo.org>
Much like PAM, not all implementations of libcrypt provide a pkg-config
file, and hence we can't find it using the old logic.
Let's fall back to the standard AC_SEARCH_LIBS-style check if the pkg-config-style
detection fails.
This fixes finding e.g. musl's libcrypt.
X-Gentoo-Bug: 827074
X-Gentoo-Bug-URL: https://bugs.gentoo.org/827074
We only need libcrypt if we're building _with_ SELinux and
_without_ PAM. We don't use libcrypt for general SELinux
with PAM.
This is mostly a correctness change as libcrypt should
generally be available (as opposed to the previous
change which fixed some real-world cases).
Fixes: f3f0fde861Fixes: #478
This github action runs a build on each of the following platforms on a
push or pull request.
- Ubuntu LTS with gcc and glibc
- Ubuntu LTS with clang and glibc
- Alpine with gcc and musl
This fixes#463.
strlen's return value isn't enough to be used
directly for (x)malloc; it doesn't include
the null byte at the end of the string.
X-Gentoo-Bug: 816900
X-Gentoo-Bug-URL: https://bugs.gentoo.org/816900Fixes: #459Fixes: #462
Sam James