On Wed, 28.01.15 16:06, Dimitri John Ledkov ([email protected]) wrote:
> On 28 January 2015 at 15:47, Martin Pitt <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
