The usual: if we find that function useful, other users of the library
will too. In particular, the v-variants are necessary to build pass-thru
wrappers.
It had two symbols which were not actually exported because they were not
listed in libsystemd.sym. They were also entirely unused in our codebase.
I don't think it makes much sense to export just those two functions, and
it doesn't make to build a string processing library in systemd either.
History of the file shows that it was created in
faaa5728d9 'utf8: export utf8 validation functions as part of sd-bus'
and hasn't gone even one non-trivial change since then ;)
It was added originally in 65f568bbeb. The API is
has stabilized pretty much, and generally follows the usual style for
libsystemd. We've held it as a public-but-private library for almost 10 years,
let's export it.
sd_netlink_sendv() and sd_nfnl_nft_*() are excluded.
libsystemd.so seems to grow by 12k.
This makes it easier to see what the test is doing.
I converted the code to use f-strings. They are already used in other scripts
necessary for build, so IIUC this is OK.
Before we had the following scheme:
mempool_enabled() would check mempool_use_allowed, and
libsystemd-shared would be linked with a .c file that provides mempool_use_allowed=true,
while other things would linked with a different .c file with mempool_use_allowed=false.
In the new scheme, mempool_enabled() itself is a weak symbol. If it's
not found, we assume false. So it only needs to be provided for libsystemd-shared,
where it can return false or true.
test-set-disable-mempool is libshared, so it gets the symbol. But then we
actually disable the mempool via envvar. mempool_enable() is called to check
its return value directly.
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.
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.
