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
The implementation is pretty straight-foward: when we get a request to
clean some type of resources we fork off a process doing that, and while
it is running we are in the "cleaning" state.
This adds basic infrastructure to implement a "clean" operation for unit
types. This "clean" operation is supposed to remove on-disk resources of
units, and is supposed to be used in a later commit to clean our
RuntimeDirectory=, StateDirectory= and so on of service units.
Later commits will open this up to the bus, and hook up service units
with this.
This also adds a new generic ActiveState called UNIT_MAINTENANCE. It's
supposed to cover all kinds of "maintainance" state of units.
Specifically, this is supposed to cover the "cleaning" operations later
added for service units which might take a bit of time. This high-level,
generic, abstract state is called UNIT_MAINTENANCE instead of the
more specific "UNIT_CLEANING", since I think this should be kept open
for different operations possibly later on that could be nicely subsumed
under this (for example, maybe a recursive chown()ing operation could be
covered by this, and similar).
This new flag suppresses error if the top-level path specified doesn't
exist. This is useful since suppressing this on the caller side isn't
easy, since ENOENT migh be propagate for some reason from further inside
and we can't distuingish that.
While we are at it, also be a bit more careful witht the various
combinations of flags.
(Note that in some cases rm_rf() was already ignoring ENOENT from
unlink() or rmdir(), however that was pretty useless, since we always
open() the top-level path with O_DIRECTORY and if that hit ENOENT we
didn't ignore the failure).
And obviously CONFIG_LINE=0 is also not logged.
The way that log_syntax_internal now looks is becoming a bit crazy, but we
can't easily conditionalize on both unit and config_file, and we have different
types, so it's not easy to make this more compact.
When using build/ directory inside of the source directory:
__FILE__: ../src/test/test-log.c
RELATIVE_SOURCE_PATH: ..
PROJECT_FILE: src/test/test-log.c
When using a build directory outside of the source directory:
__FILE__: ../../../home/zbyszek/src/systemd-work/src/test/test-log.c
RELATIVE_SOURCE_PATH: ../../../home/zbyszek/src/systemd-work
PROJECT_FILE: src/test/test-log.c
