On May 2, 2007, at 6:37 PM, Anyang Ren wrote:
On 5/2/07, David Hyatt <[EMAIL PROTECTED]> 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
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
