Lennart Poettering
8890ec82f5
ASSERT_SE_PTR() is like ASSERT_PTR() but uses assert_se() instead of assert() internally. Code should use ASSERT_SE_PTR() where the check should never be optimized away, even if NDEBUG is set. Rationale: assert() is the right choice for validating assumptions about our own code, i.e. checking conditions that are "impossible" to not hold, because we ourselves hacked things up the "right" way of course. assert_se() is the right choice for tests that come with a weaker guarantee, they encode assumptions over other's API behaviour, i.e. whether something can fail there or not. When developing tools that are not oom-safe assert_se() is the right choice: we know that on Linux OOM doesn't really happen, even though theoretically the API allows it to happen. Usecase for ASSERT_SE_PTR() is mostly the fatal memory allocation logic for EFI memory allocations. So far it used regular assert() i.e. OOM failurs would be totally ignored if NDEBUG is set. We'd rather have our EFI program to print an assert message and freeze instead though.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.