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.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407470
Received on 2009-10-14 12:00:41 CEST