When optimizing, the compiler will most likely replace the call to memcmp(),
but at -O0, the code that is emitted builds the call preamble and does the
call. Let's use the same pattern as with sd_id128_is_null() and
sd_id128_is_allf() and avoid the call.
Fixes a bug introduced by 578cd1855b.
The function `data_object_in_hash_table()` calls
`journal_file_move_to_object()` with `OBJECT_DATA`. Hence,
previously obtained pointer to a data object may be now invalid.
Fixes#23794.
Otherwise, e.g.
---
KERNEL=="foo", ACTION!="remove", ENV{SYSTEMD_WANTS}+="test.service"
---
then the service will not triggered on CHANGE uevents for the device even
if the service is already stopped.
Scripts used to detect files that should be in POTFILES.in, like
intltool-update -m used on https://l10n.gnome.org/module/systemd/,
falsely detect this file as containing translations. Avoid this
behavior by putting the file in POTFILES.skip.
The way the UEFI spec defines BOOLEAN is fully compatible to stdbool, so
it is perfectly safe to switch to it. Although any other values than 0/1
are undefined by the spec, we could theoretically have cases where a
sloppy firmware hands us a bad BOOLEAN (since gnu-efi/edk2 declare it
as uint8_t). So any uses where we pass a pointer to BOOLEAN are left
untouched.
The macro is ugly and annoying to use and provides no real benefit. The
only reason to use it would be to allow warnings to go through. But any
EFI APIs we call do not return warning status codes or we do not check
the return value anyway. The only other case would be BS->StartImage,
where we already treat anything other than EFI_SUCCESS as an error
anyway.
This also helps the compiler and code analyzers to better reason about
the code. In particular, this can help reduce use of uninitialized
variable warnings.
This removes the fundamental typedefs in favor of just using standard C
types. These are all used internally anyway and also do not do anything
special to warrant any redefinition to EFI types.
Even for BOOLEAN we can safely use stdbool. The defition from the EFI
specification is fully compatible, including making any other values
than 0/1 as undefined.
The exception is sd_char as those need to be char16_t. The typedef is
moved to string-util-fundamental.h instead.
so we can run it under nspawn in CIs which don't support nested KVM, but
avoid running it twice (both under nspawn and qemu) in CIs which support
both methods.