]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
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)
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

index dd257eadfe800931638ed218b7943ae4777ac582..82056998bd64cce6e17c84cd61ee6d1368060321 100644 (file)
@@ -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);