Le lundi 22 novembre 2010 Ã 15:50 -0800, Andrew Morton a Ãcrit : > Well. We certainly assume in many places that > > struct foo { > int a; > int b; > } f = { > .a = 1, > }; > > will initialise b to zero. But I doubt if much code at all assumes > that this initialisation patterm will reliably zero out *holes* in the > struct. > We did such assertions in the past, we were wrong. Check commit 1c40be12f7d8ca1d387510d39787b12e512a7ce8 for an example (net sched: fix some kernel memory leaks) I guess we must make a full audit of all C99 initializers or structures copied to userspace, giving a name to hidden holes, to force gcc to init them to 0. # cat try.c struct s { char c; long l; }; void bar(void *v) { unsigned long *p = v; printf("%lx %lx\n", p[0], p[1]); } int main() { struct s s1 = { .c = 1, .l = 2, }; bar(&s1); return 0; } # gcc -O2 -o try try.c # ./try 8049401 2 Strangely, if we remove ".l = 2," line, gcc emits code to clear al the fields main: pushl %ebp movl %esp, %ebp andl $-16, %esp subl $32, %esp leal 24(%esp), %eax movl $0, 24(%esp) movl %eax, (%esp) movl $0, 28(%esp) movb $1, 24(%esp) call bar xorl %eax, %eax leave ret -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html