| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
|
| |
|
|
|
|
|
|
|
|
| |
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
|
| |
|
|
| |
src/basic (1/6)
|
| |
|
|
|
| |
Let's systematically make use of reallocarray() whereever we invoke
realloc() with a product of two values.
|
| |
|
|
| |
gcc complains that len might be used unitialized, but afaict, this is not true.
|
| | |
|
| |
|
|
| |
We wrote them ourselves -- they shouldn't contain invalid sequences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The environment variables we've serialized can quite possibly contain
characters outside the set allowed by env_assignment_is_valid(). In
fact, my environment seems to contain a couple of these:
* TERMCAP set by screen contains a '\x7f' character
* BASH_FUNC_module%% variable has a '%' character in name
Strict check of environment variables name and value certainly makes sense for
unit files, but not so much for deserialization of values we already had
in our environment.
|
| | |
|
| |
|
|
| |
Follow up for fe102d6ab15731a199a7ea9f38c4f68d8959f86c.
|
| |
|
|
| |
Fixes #6152.
|
| |
|
|
|
|
| |
Apart from bugs (as in #6152), this can happen if we ever make
our requirements for environment entries more stringent. As with
the rest of deserialization, we should just warn and continue.
|
| |
|
|
| |
If cunescape succeeds, but the assignment is not valid, uce is not freed.
|
| | |
|
| | |
|
|
|
Some functionality has been exported to the following files:
- src/basic/env-util.[hc]
- src/basic/exec-util.[hc]
- src/shared/nsflags.[hc]
The content of these files is now needed in elogind, and the files have been
added as-is. Cleanup is done later.
Further the header
src/basic/formats-util.h
has been renamed to
src/basic/format-util.h
|
