This is a natural use case, and instead of defining a wrapper to do this
for us, let's just make this part of the API. Calling with NULL was not
allowed, so this is not a breaking change to the interface.
(After sd_event_source_is_enabled was originally added, we introduced
sd_event_source_disable_unref() and other similar functions which accept
NULL. So not accepting NULL here is likely to confuse people. Let's just
make the API usable with minimal fuss.)
Before, sd_netlink_message_read() expected to fill a buffer completely,
and would return -EIO if the attribute being read was shorter than the
buffer. This means that the function can be used to "peek" into attributes
(by specifying a short buffer to just read part of the attribute), but
cannot be used to read something into a union without knowing beforehand
which specific field in the union is being filled. That latter operation
seems more useful (messages are short, so we don't really need to do partial
reads), so let's allow reads that don't fill the output buffer completely.
In places the text was overly formal, e.g. "an 128-bit ID" was repeated, even
though it is clear from the context that we're talking about this type of ID.
OTOH, in other places the text was informal, e.g. "You can use …".
Also, "you may use f() to frob" → "f() frobs". The text without all the
flourishes is easier to read.
sd_id128_in_set_sentinel() was described only in passing when taking about
sd_id128_in_set(), now it gets is own brief paragraph.
The synopsis was missing.
We find this function useful in our code, so no reason not to export it.
I changed the order of last two words in the name to match the arguments.
(With "equal_string" I expected sd_id128_t first, string second, but in
actual use, the second argument is usually a long constant so it's nice
to keep this order of arguments.)
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.
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Yu Watanabe
Michael Biebl
David Tardon
Sam James
Jan Macku
Piotr Drąg
Jan Janssen