On Wed, May 21, 2014 at 10:46 AM, Lennart Poettering <[email protected]> wrote: > On Wed, 21.05.14 10:29, Thomas H.P. Andersen ([email protected]) wrote: > >> >> On Tue, May 20, 2014 at 5:43 PM, Lennart Poettering >> <[email protected]> wrote: >> > On Mon, 19.05.14 19:52, Tom Gundersen ([email protected]) wrote: >> > >> >> > _public_ int sd_peer_get_session(int fd, char **session) { >> >> > - struct ucred ucred; >> >> > + struct ucred ucred = {}; >> >> >> >> I can't reproduce this warning, but more importantly, why is this >> >> necessary in this function and not the subsequent noes (which all seem >> >> to be more or less equivalent)? >> > >> > Hmm, given the current flakiness of the gcc warnings when -flto is in >> > the mix I think we should follow the rule that we do not fix gcc >> > warnings that show up only with -flto is used. We can revisit that in a >> > few years when LTO has settled a bit, but for now I am pretty sure >> > trying to fix all those issues is a waste of time and certainly don't >> > improve our code... >> > >> > Cristian, are those warnings you saw related to -flto? >> >> The warning in namespace_open is not related to LTO. It shows up with >> "autogen.sh g && make" and that gets in the way for my workflow. It >> would make my life easier if we could silence it with the fix in this >> patch or suppress it with >> #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" >> >> Would that be okay? > > Ok, fixed that one. It is a false positive, but I can see why gcc gets > confused, and this sounds OK to fix. Have done so now. Please test!
Works great. Thanks Lennart! _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
