[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: Philip Martin <philip_at_codematters.co.uk>
Date: Wed, 14 Oct 2009 12:03:34 +0100

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:

  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

Received on 2009-10-14 13:04:30 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.