[webkit-dev] Fix for Vector::m_inlineBuffer alignment?

[Paul Pedriana]

I agree that a union is most portable, but there are two problems with it:

    - The C++ Standard (section 9.5 p1) disallows union members that
       have ctors, dtors, or assignment operators. This includes the case
       whereby the class is the only non-POD of the union.

    - It would create an instance of type T. Thus an empty Vector would
       construct an instance of T, resizing it would overwrite the 
instance of T,
       and on destruction it would destruct the T.

Paul



> On Sep 4, 2008, at 1:20 AM, Paul Pedriana wrote:
>
>> Well the proposed solution in
>> <https://bugs.webkit.org/show_bug.cgi?id=16925> doesn't work, as VC++
>> doesn't accept that syntax. And the solutions in
>> <https://bugs.webkit.org/show_bug.cgi?id=19775> whereby a uint32_t or
>> uint64_t buffer are made don't work for larger types and use more memory
>> than necessary. They might be useful as a fallback for compilers that
>> don't support alignment directives, though the primary implementations
>> of every compiler that I work with (GCC, VC++, CodeWarrior, EDG, SN,
>> IBM) support it.
>
> The buffer should definitely remain char to avoid strict aliasing 
> problems. However, I think the most portable way to ensure alignment 
> is to union the buffer with a one-element array of the template 
> parameter type T.
>
>  - Maciej
>
>
>> I'll make a patch and attach it to
>> <https://bugs.webkit.org/show_bug.cgi?id=16925>, if that's OK.
>
>
>> Paul
>>
>>> On Sep 4, 2008, at 2:05 AM, Paul Pedriana wrote:
>>>
>>>> I see that JavaScriptCore/wtf/Vector.h has this:
>>>>
>>>>   // FIXME: Nothing guarantees this buffer is appropriately aligned to
>>>> hold objects of type T.
>>>>   char m_inlineBuffer[m_inlineBufferSize];
>>>
>>>
>>> We have a bug for this:
>>> <https://bugs.webkit.org/show_bug.cgi?id=16925>. Also,
>>> <https://bugs.webkit.org/show_bug.cgi?id=19775>.
>>>
>>> There are several patches and suggestions in these bugs, which wait
>>> for someone to submit them as clean patches.
>>>
>>> - WBR, Alexey Proskuryakov
>>>
>>>
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>