Hi Geert!
On 06/22/2018 12:54 PM, Geert Uytterhoeven wrote:
>>> If anything relies on having a hole in between the two fields, explicit
>>> padding should be added.
>>
>> Well, I don't think we can add this change as this reduces the size of
>> the bitfield. Do you think we can just cut it in half without any issues?
>
> CSSProperty contains:
>
> StylePropertyMetadata m_metadata;
> RefPtr<CSSValue> m_value;
>
> StylePropertyMetadata contains:
> uint16_t m_propertyID : 10;
> uint16_t m_isSetFromShorthand : 1;
> uint16_t m_indexInShorthandsVector : 2; // If this property was
> set as part of an ambiguous shorthand, gives the index in the
> shorthands vector.
> uint16_t m_important : 1;
> uint16_t m_implicit : 1; // Whether or not the property was set
> implicitly as the result of a shorthand.
> uint16_t m_inherited : 1;
> uint16_t pad;
>
> So the bitfield is in the first uint16_t, not in a uint32_t (yes, that matters
> on big endian).
But our problem is not endianess-related, is it? Our problem is that the
default alignment on m68k is 16 bits.
> Oops, I did miss StylePropertyMetadata already has padding.
> So the sizes of CSSProperty and SameSizeAsCSSProperty should already match.
>
> To avoid future endianness issues, you still may want to reflect this in
> SameSizeAsCSSProperty:
>
> --- webkitgtk-2.20.3/Source/WebCore/css/CSSProperty.cpp.orig
> 2018-06-22 10:40:49.389060321 +0200
> +++ webkitgtk-2.20.3/Source/WebCore/css/CSSProperty.cpp 2018-06-22
> 12:50:51.005024268 +0200
> @@ -29,7 +29,8 @@
> namespace WebCore {
>
> struct SameSizeAsCSSProperty {
> - uint32_t bitfields;
> + uint16_t bitfields;
> + uint16_t pad;
> void* value;
> };
I'm confused. The endinaness is not our problem at the moment, is it?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
