On Thu, Dec 18, 2014 at 8:59 AM, H. Peter Anvin <h...@zytor.com> wrote:
>>
>> will leave .lm uninitialized. This means that anything in the
>> kernel that reads user_desc.lm for 32-bit tasks is unreliable.
>
> No, it won't. However, if you initialize this dynamically field by
> field rather than as an initializer, then you are correct.
Actually, even with a full initializer, unnamed parts of a structure
(so padding bytes between things, but for bitfields also unnamed
alignment fields etc) are basically "all bets are off". They are *not*
guaranteed to be initialized to zero.
So if you have a structure like
struct {
unsigned int a:5;
unsigned int b;
} x = { .a = 0, .b = 0 };
afaik the compiler is not guaranteed to initialize the left-over bits
in the first word. Because they simply don't "exist" as far as the C
language is concerned.
On the other hand, if you do
struct {
unsigned int a:5, unused:27;
unsigned int b;
} x = { .a = 0, .b = 0 };
then the 'unused' bits are guaranteed to be initialized to zero.
(Static allocations in the BSS are obviously zeroed for other reasons,
so there are no "left-over" bits there to worry about,. So in practice
the above is only about dynamic initializers).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
