From 2091c779314133d8a4b68283b255d7388a5ec5ff Mon Sep 17 00:00:00 2001 From: Thomas Haller Date: Sat, 22 Jan 2022 15:02:04 +0100 Subject: [PATCH] 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 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd/sd-event/sd-event.c b/src/libsystemd/sd-event/sd-event.c index dd257eadfe..82056998bd 100644 --- a/src/libsystemd/sd-event/sd-event.c +++ b/src/libsystemd/sd-event/sd-event.c @@ -2095,7 +2095,7 @@ _public_ int sd_event_add_inotify( sd_event_inotify_handler_t callback, void *userdata) { - sd_event_source *s; + sd_event_source *s = NULL; /* avoid false maybe-uninitialized warning */ int fd, r; assert_return(path, -EINVAL);