Branko Čibej wrote:
> Philip Martin wrote:
>
>> Branko Cibej <brane_at_xbc.nu> writes:
>>
>>
>>
>>> struct. Yes, there can be padding, and yes, using (apr_p)calloc to
>>> allocate the struct avoids hashing random padding bits.
>>>
>>>
>> Is that correct? When code writes to a struct can it change the
>> padding bits? I'm not aware of any requirement on the compiler to
>> avoid changing those bits. Consider a machine where writing 32-bit
>> values is faster than writing smaller values: a compiler may choose to
>> use 32-bit writes to change a 16-bit value when the other 16-bits are
>> padding; the padding bits would then get random values.
>>
>>
> There is a requirement that any optimization have no side-effects that a
> program can detect. Widening a write the way you propose would certainly
> be detected with memcmp(); so I believe that, while a compiler is free
> to generate wider reads, or use wider arithmetic where overflow is not
> affected, etc., it's not allowed to generate wider writes that would
> affect padding.
>
> At least, that's my understanding.
>
By the way, I believe the compiler *is* allowed to widen write to
stack-based variables, because any kind of fiddling with reading stack
padding is not well-defined; even its existence can't be determined in a
conformant way, since results of arithmetic on unrelated pointers are
undefined. This is quite unrelated to the fact that it does work, and
that valgrind et al. would scream at you if you changed stack padding.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407483
Received on 2009-10-14 12:25:19 CEST