On Fri, Apr 5, 2013 at 2:50 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Sun, 31.03.13 15:57, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
>> Hi everyone,
>> I'm pretty sure this a good step, but just in case, I'm posting
>> here for review (more of the general idea, not the specifics,
>> because the patch is pretty well checked by the compiler...).
>>
>> Zbyszek
>>
>> ---- patch ----
>>
>> Before, we would initialize many fields twice: first
>> by filling the structure with zeros, and then a second
>> time with the real values. We can let the compiler do
>> the job for us, avoiding one copy.
>
> Hmm, I assumed the compiler would handle memset on its own anyway these
> days, at least if you specifiy -O2 or so... Did you try with
> optimization on?
>
>> else {
>> - struct sched_param p;
>> + struct sched_param p = {};
>>
>> - zero(p);
>
> I would have assumed that particularly in cases like this the compiler
> would generate the exact same code... Mayb I am overestimating gcc's
> handling of memset however...
>
> One could argue that zeroing out the struct in this particular case is
> totally unnecessary anyway, and we could just get rid of it entirely...
>
>> if (sched_getparam(0, &p) >= 0)
>> n = p.sched_priority;
>> - union sockaddr_union sa;
>> + union sockaddr_union sa = {
>> + .un.sun_family = AF_UNIX,
>> + .un.sun_path = "/run/systemd/journal/stdout",
>> + };
>
> For cases like this, this definitely appears worthwile! (It makes things
> more readable even...)
>
>> struct sock_filter *f;
>> - struct sock_fprog prog;
>> + struct sock_fprog prog = {};
>
> I wonder if we should have a macro for this... {} looks so ugly... or
> maybe not...
it doesn't when you get used to it ;-)
Lucas De Marchi
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
