[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r39997 - trunk/tools/server-side

From: Branko Cibej <brane_at_xbc.nu>
Date: Wed, 14 Oct 2009 12:00:03 +0200

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

Received on 2009-10-14 12:00:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.