[systemd-devel] initializing _cleanup_* variables [was: [PATCH 01/12] fsckd daemon for inter-fsckd communication]

[Lennart Poettering]

On Wed, 28.01.15 16:06, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:

> On 28 January 2015 at 15:47, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> > Hey Zbyszek,
> >
> > Zbigniew Jędrzejewski-Szmek [2015-01-28 15:37 +0100]:
> >> > +static int handle_requests(int socket_fd) {
> >> > +        Clients *first = NULL;
> >> > +        usec_t last_activity = 0;
> >> > +        int numdevices = 0, clear = 0;
> >> > +        double percent = 100;
> >> > +        _cleanup_fclose_ FILE *console = NULL;
> >> NULL not necessary (and you don't have it in similar circumstances above ;))
> >
> > How is that not necessary? Just because the very next line initializes
> > it, and there is no exit path before? Because in the general case it
> > certainly is necessary, otherwise the _cleanup_ handler will try to
> > free/close/clean up a random pointer value and crash.
> >
> > So IMHO it's a good defensive habit to always init _cleanup_* vars
> > with NULL. In the future someone might put some code with "return"
> > before the fopen() below, and then get a crash.
> >
> > Or is there some gcc magic that I missed? (I thought only global
> > variables were guaranteed to be NULL, not stack vars).
> >
> 
> Well, during systemd build there are some -Wmaybe-uninitialized
> warnings.... in most cases it is code similar to the above case or
> like checking r || check uninitialised variable. Shall we fix all of
> them? In most cases it would be of limited gain, but at least it will
> be clear to see when -Wmaybe-uninitalized warnings catches a real
> thing.
> 
> (or is my compiler old and has false positives?)

This is probably caused by LTO. The gcc warnings when using LTO are
not useful. While hacking it's a really good idea to disable LTO, the
warnings get more useful. It also saves you a lot of time to do so,
since LTO is awfully slow. 

Lennart

-- 
Lennart Poettering, Red Hat