On Tue, Nov 23, 2010 at 03:45:18PM +0100, walter harms wrote: >Am 23.11.2010 15:01, schrieb AmÃrico Wang: >> On Mon, Nov 15, 2010 at 08:12:21PM +0100, Eric Dumazet wrote: >>> >>> In my understanding, gcc should initialize all holes (and other not >>> mentioned fields) with 0, even for automatic storage [C99 only mandates >>> this on static storage] >>> >>> I tested on x86_64 and this is the case, but could not find a definitive >>> answer in gcc documentation. >>> >> >> Yeah, this is not clearly defined by C99 I think, but we can still >> find some clues in 6.2.6.1, Paragraph 6, >> >> " >> When a value is stored in an object of structure or union type, >> including in a member object, the bytes of the object representation >> that correspond to any padding bytes take unspecified values. >> " >> >> So we can't rely on the compiler to initialize the padding bytes >> too. >> >hi all, >as we see this is not a question of c99. >Maybe we can convince the gcc people to make 0 padding default. That will not solve the >problems for other compilers but when they claim "works like gcc" we can press then to >support this also. I can imagine that this will close some other subtle leaks also. > >People that still want a "undefined" (for what ever reason) can use an option to enable it >again (e.g. --no-zero-padding). Well, IMHO, the default behavior should be "undefined", thus "-fzero-padding" is needed. But, you know, I am not a compiler people at all. :) > >do anyone have a contact so we can forward that request ? > gcc@xxxxxxxxxxx ? -- Live like a child, think like the god. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
