Branko Čibej <brane_at_xbc.nu> writes:
> 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.
A conforming program cannot rely on the value of the padding bytes so
I don't think the optimisation argument works. C99 standard states:
6.2.6.1/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.
I think that allows writes to the padding bytes irrespective of any
optimisations.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407487
Received on 2009-10-14 13:04:30 CEST