lkml.org 
[lkml]   [2010]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] fs: select: fix information leak to userspace
On Wed, Nov 24, 2010 at 11:46:33AM +0000, P??draig Brady wrote:

> Looks like gcc is following the standard exactly.
>
> C90 - 6.5.7
> C99 - 6.7.8
>
> If there are fewer initializers in a brace-enclosed list than
> there are elements or members of an aggregate ... the remainder
> of the aggregate shall be initialized implicitly the same as
> objects that have static storage duration.

Incorrect. See 6.2.6.1 in C99; basically, padding bytes have unspecified
contents. Implementation is allowed to leave them in any state (including
not bothering to copy them when doing struct assignments, etc.). See
Appendix J (portability issues) as well.

The text you are quoting is about handling of missing initializers - it
essentially refers you back to the rules in 6.7.8p{9,10} (for arithmetical
types use zero, for pointers - null pointer, for arrays - apply recursively
to each array member, for structs - apply recursively for each named
member, for unions - apply recursively for the first named member). That's
it - nothing in the standard says how to initialize padding. Note that
these rules are _not_ guaranteed to be "fill everything with zero bits";
it often will be true, but it's implementation-dependent. Implementation
may decide to fill padding with all-zeroes; it's not required to do so.

The bottom line: if you rely on that, you are relying on non-portable
details of compiler behaviour. Moreover, the authors are not even
required to document what they are doing or to keep that behaviour
consistent.


\
 
 \ /
  Last update: 2010-12-15 10:53    [W:0.057 / U:1.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site