C's strerror() function does not return a "const char *" pointer
for the string. That has historic reasons and C99 even comments
that "[t]he array pointed to shall not be modified by the program".
Make the strerror_safe() wrapper correct this and be more strict
in this regard.
In recent systemd-nspawn we wouldn't parse init args like systemd.log-level=debug.
This is because we wouldn't even look at /proc/1/cmdline.
$ systemd-nspawn -n cat /proc/1/stat
1 (cat) R 0 1 1 34816 ....
^^^^^
34816 is 136:0 a.k.a. /dev/pts/0.
So far, we'd use hashmap_free_free to free both keys and values along with
the hashmap. I think it's better to make this more encapsulated: in this variant
the way contents are freed can be decided when the hashmap is created, and
users of the hashmap can always use hashmap_free.
This could already be done by calling unit_name_is_*(), but if we don't know
if the argument is a valid unit name, it is more convenient to have a single
function which returns the type or possibly an error if the unit name is not
valid.
The values in the enum are sorted "by length". Not really important, but it
seems more natural to me.
Some distros install nologin as /usr/sbin/nologin, others as
/sbin/nologin.
Since we can't really on merged-usr everywhere (where the path wouldn't
matter), make the path build time configurable via -Dnologin-path=.
Closes#13028
The enum order will be used to order jobs in the job queue.
Make sure that unit types that fork aditional processes come first to
maximize parallelism.
This restores proper speed with asan builds with gcc 9.1.1.
Fixes#12997.
$ rpm -q gcc
gcc-9.1.1-2.fc31.x86_64
$ time ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1 UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 build-rawhide-sanitize/test-conf-parser
(old) 86.99s user 20.22s system 361% cpu 29.635 total
(new) 3.05s user 0.29s system 99% cpu 3.377 total
Size is increased a bit:
$ size build/systemd
(old) 1683421 246100 1208 1930729 1d75e9 build/systemd
(new) 1688237 246100 1208 1935545 1d88b9 build/systemd
... but that's <0.1%, so we don't really care.
The comment explains the reason: we'd wait for the second \n
and then ungetc() it. Then the buffered \n would cause a problem
when the next prompt was issued, so in effect it wasn't possible
to answer the second question.
It's hard to even say what exactly this combination means. Escaping is
necessary when quoting to have quotes within the string. So the escaping of
quote characters is inherently tied to quoting. When unquoting, it seems
natural to remove escaping which was done for the quoting purposes. But with
both flags we would be expected to re-add this escaping after unqouting? Or
maybe keep the escaping which is not necessary for quoting but otherwise
present? This all seems too complicated, let's just forbid such usage and
always fully unescape when unquoting.
Let's hide non-UTF-8 locales by default. It's 2019 after all.
Let's add an undocumented env var to reenable listing them though.
This should substantially shorten the list of choices we offer users,
and only show realistic choices.
note that only firstboot and localectl make use of this information, and
both allow configuration of values outside of these lists, hence all
this change does is hide legacy options, but they are still available if
you know what you do, and that's how it should be.
Let's drop the 'static' logic when a parameter can be NULL.
I think asan/ubsan are right here, judging by the C99 spec language:
"A declaration of a parameter as ‘‘array of type’’ shall be adjusted to
‘‘qualified pointer to type’’, where the type qualifiers (if any) are
those specified within the [ and ] of the array type derivation. If the
keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the
corresponding actual argument shall provide access to the first element
of an array with at least as many elements as specified by the size
expression."
If we specify NULL, then we certainly don't pvode access to any valid
array.
Fixes: #13039
This decorator tells compilers that the memory we return is shorter than
it actually is, thus triggering misleading bad memory access complaints.
Fixes: #13026
