[webkit-dev] Bit fields cause Purify to report UMRs

Oliver Hunt ojh16 at student.canterbury.ac.nz
Thu May 3 04:35:50 PDT 2007


On May 2, 2007, at 6:37 PM, Anyang Ren wrote:


> On 5/2/07, David Hyatt <hyatt at apple.com> wrote:
>
>> This seems like a pretty sad technical limitation of Purify.
>>
>
> Yes.  I thought about this problem for a while, and the best
> solution I came up with requires changes to compilers.
>
> Using my example and pseudocode:
>
>  Suppose bit field x is the 0th bit (least significant bit) of a  
> word w
>  and bit field y is the 1st bit.  To initialize x to a and y to b, the
>  compiler would generate this pseudocode:
>
>     unsigned w;  // uninitialized
>
>     w |= (a & 0x1);  // x(a)
>     w |= (b & 0x1) << 1;  // y(b)
>
> In generating the code for a constructor, the compiler could either
> initialize w to 0, or use = instead of |= in the very first bit field
> initializer.
>
Once again the problem is that the tool is lacking, not the  
compiler.  The compiler
codegen *works* it is the tool that doesn't.

(
Slightly off topic:
I *really* doubt any decent compiler would generate that sort of code..
in all likelihood the compiler would generate
w = (b & 1) << 1 | (a & 1);

... actually it would probably do something crazier -- remember  
compilers
often do *very* crazy things behind the scenes, trying to predict  
behaviour
would likely just cause pain and agony all round.
)


>
> Regarding the "incorrect" structure size on Windows because MSVC
> packs 'unsigned' and 'bool' bit fields separately, would you consider
> declaring all bit fields as 'unsigned'?
>

Hmmm -- there are probably occasions where we want signed bitfields  
(i have
considered using them in a particularly ugly area of our svg impl)

Anyhoo, how is it incorrect? does sizeof return a different size from  
the actual
size in memory, or are the structs just bigger than they need to be?

It might conceivably be possible to reorder a few cases where this  
causes problems,
but i still don't like the prospect of substantial changes to the  
codebase because a single
(albeit major) tool has problems.

--Oliver


> -- 
> Anyang Ren
> Open source developer
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>





More information about the webkit-dev mailing list