Suggested at https://github.com/systemd/systemd/pull/25805#discussion_r1054871210
> we now write multiple files and we cannot possibly guarantee that
> either both updates worked or neither. unix fs apis simply have
> no concept that would allow us to implement that. hence I think
> we should update what we can, log about what we cannot, but return
> success as long as our in-memory state was updated.
Similary, this also renames context_free_x11() -> context_clear_x11(),
to make it clear that these functions do not free Context.
Also, this makes context_clear() support to be called more than once.
- add missing assertions,
- rename arguments for storing results,
- always initialize results on success,
- use _cleanup_ attribute at more places, etc.
These combine strndup() + strspn()/strcspn() into one.
There are a bunch of strndupa() calls that could use similar treatment
(or should be converted to strdup[c]spn(), but this commit doesn't
bother with that.
Since commit 1ad6e8b302, unsetting an environment
variable means restoring it to its default value.
However this doesn't work well when localed updates locale.conf. Indeed when a
variable is removed from that file, localed calls "UnsetAndSetEnvironment"
method which restores the default values of the unset variables obtained by
PID1 when it first read locale.conf. But since locale.conf has been updated,
these default values might be outdated and localed needs to instruct PID1 to
read locale.conf again.
Reloading PID1 configuration is quite an heavy operation for this purpose but
there's no other way unless we change again the meaning of "UnsetEnvironment"
or we introduce a new method that really unset an env variable.
That said given the fact that localed modifies locale.conf, it should have an
effect on PID1 default environment rather than on the environment explicitly
set by the user (m->client_manager).
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
See https://bugzilla.redhat.com/show_bug.cgi?id=2121106 for the
background on this. One of Fedora's QA folks ran an install
and chose two keyboard layouts: Czech (qwerty) and US. Due to
the sad details of how the whole logic flow for trying to decide
what kbd layout best matches a given xkb config works (see
details in the bug comments), we wound up deciding the best-
matching kbd layout for this situation was cz-us-qwertz, which
is a czech/us switched layout, but is qwertz, not qwerty. This
seems like a poor outcome. Adding this line should result in us
picking cz-qwerty in this case. Which may be the 'legacy'
cz-qwerty.map from upstream kbd project (which is switched
cz/us), or may be the auto-converted xkb layout (which obviously
isn't switched). But either way, at least its primary mode is
Czech qwerty, which seems like a *better* choice than a layout
whose primary mode is Czech qwertz.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
All users were setting this to some static string (usually "-"), so let's
simplify things by not doing strdup, but instead limiting callers to a fixed
set of values. In preparation for the next commit, the function is renamed from
"empty" to "replacement", because it'll be used for more than empty fields. I
didn't do the whole string-table setup, because it's all used internally in one
file and this way we can immediately assert if an invalid value is passed in.
Some callers were (void)ing the error, others were ignoring it, and others
propagating. It's nicer to remove the boilerplate.
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
The approach to use '''…'''.split() instead of a list of strings was initially
used when converting from automake because it allowed identical blocks of lines
to be used for both, making the conversion easier.
But over the years we have been using normal lists more and more, especially
when there were just a few filenames listed. This converts the rest.
No functional change.
Previously the mkdir_label() family of calls was implemented in
src/shared/mkdir-label.c but its functions partly declared ins
src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird
(and wrong).
Let's clean this up, and add a proper mkdir-label.h matching the .c
file.
(Or when -H is used, since -H and -M are incompatible.)
Note that the slightly unusual form with separate boolean variables (hint_vars,
hint_addr) instead of e.g. a const char* variable to hold the message, because this
way we don't trigger the warning about non-literal format.
This test makes assumptions on the availability of some mappings contained in
kbd-model-map and therefore strongly relies on the version shipped by
upstream. IOW the test is likely to fail if it's installed on a system with a
more comprehensive kbd-model-map.
This patch makes the upstream kbd-model-map file available via a symlink in
test/testdata/test-keymap-util dir and makes sure that this specific version is
always used by test-keymap-util regardless of whether the test is installed and
run on a different system or directly run (optionally via meson) from the
project working dir.
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
When the flag COPY_ALL_XATTRS is set, it causes the complete set of xattrs
to be copied. If the flag is unset, only xattrs from the "user" namespace
are copied.
Fixes#17178.