| Age | Commit message (Collapse) | Author |
|---|
|
`seed_dir` gets allocated via xstrdup but never gets freed - which
clang-tidy flags as a memory leak.
instead of free-ing the allocation, just don't allocate to begin with
since there's no need for it.
also bump the copyright year.
|
|
same rational as 459783bb
Bug: https://github.com/OpenRC/openrc/issues/589
|
|
same rational as 459783bb
Bug: https://github.com/OpenRC/openrc/issues/589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
Needed for clang-tidy prep work, as it requires headers to work standalone
(which is useful anyway).
|
|
this was reported by codeql's scan as a TOCTOU bug. while that's true in
theory, i don't believe it would've had any practical effect.
a better justification for this change might be the fact that it
upgrades from `utime` (which is depreciated by POSIX [0]) to `futimens`.
[0]: https://www.man7.org/linux/man-pages/man3/utime.3p.html#FUTURE_DIRECTIONS
|
|
malloc (called by xasprintf) is not async-signal-safe. beside, the
string here is constant, so there's no need to malloc it all.
eerrorx isn't async-signal-safe either (due to calling fprintf and exit)
but consequence of them are _typically_ not as grave as calling malloc
while it's internal state is inconsistent.
Bug: https://github.com/OpenRC/openrc/issues/589
|
|
|
|
For -Wmissing-noreturn.
|
|
For -Wmissing-noreturn.
|
|
For -Wmissing-noreturn.
|
|
|
|
|
|
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.
|
|
|
|
This one is a bit odd, it didn't get fixed in e273b4e08ee0ebc1a001d60e2a5b65a9553a8a8a,
and goes all the way back to cb9da6a262b60255cd037f20b4cde3ab2c8a1e6a.
|
|
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.
|
|
On systems with a very large RLIMIT_NOFILE, calling close() in a loop
from 3 to getdtablesize() effects an enormous number of system calls.
There are better alternatives. Both BSD and Linux have the closefrom()
system call that closes all file descriptors with indices not less than
a specified minimum. Have start-stop-daemon call closefrom() on systems
where it's implemented, falling back to the old loop elsewhere.
Likewise, calling fcntl(i, F_SETFD, FD_CLOEXEC) in a loop from 3 to
getdtablesize() raises a similar performance concern. Linux 5.11 and
onward has a close_range() system call with a CLOSE_RANGE_CLOEXEC flag
that sets the FD_CLOEXEC flag on all file descriptors in a specified
range. Have supervise-daemon utilize this feature on systems where it's
implemented, falling back to the old loop elsewhere.
|
