sd-event: workaround maybe-uninitalized warning in sd_event_add_inotify()
authorThomas Haller <thaller@redhat.com>
Sat, 22 Jan 2022 14:02:04 +0000 (15:02 +0100)
committerYu Watanabe <watanabe.yu+github@gmail.com>
Sun, 23 Jan 2022 04:10:31 +0000 (13:10 +0900)
commit2091c779314133d8a4b68283b255d7388a5ec5ff
treec9036703e304fb08eafe43ef3f0b4cc45463716a
parente7642152ae6e867fc569206e905464321a41e58a
sd-event: workaround maybe-uninitalized warning in sd_event_add_inotify()

With LTO, the compiler might think that the variable is uninitialized
(from NetworkManager's fork, with gcc-11.2.1-1.fc35):

    src/libnm-systemd-core/src/libsystemd/sd-event/sd-event.c: In function 'sd_event_add_inotify':
    src/libnm-systemd-core/src/libsystemd/sd-event/sd-event.c:2120: error: 's' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     2120 |                 *ret = s;
          |
    src/libnm-systemd-core/src/libsystemd/sd-event/sd-event.c:2102: note: 's' was declared here
     2102 |         sd_event_source *s;
          |
    lto1: all warnings being treated as errors

In particular, that would happen for codepaths where event_add_inotify_fd_internal()
returns `-errno`, and the compiler cannot be sure that the returned value will
be negative. Technically, the compiler is right, but we rely on libc functions
to set errno correctly, so this only happens in code paths, where something
bad already happend.

While LTO is prone to such false warnings, we are largely able to build systemd
without warnings. So it is feasible and we should make the effort of working
around warnings as they appear.
src/libsystemd/sd-event/sd-event.c