"Ronald S. Bultje" <[email protected]> writes:

> Hi,
>
> 2011/7/10 Måns Rullgård <[email protected]>:
>> "Ronald S. Bultje" <[email protected]> writes:
>>
>>> From: Anton Mitrofanov <[email protected]>
>>>
>>> ptrdiff_t can be 4 bytes, which leads to the next element being 4-byte
>>> aligned and thus at a different offset than intended. Using a fixed 8-byte
>>> element for uv_off_px/byte fixes that.
>>>
>>> Signed-off-by: Ronald S. Bultje <[email protected]>
>>> ---
>>>  libswscale/swscale_internal.h |    4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
>>> index b602541..7166667 100644
>>> --- a/libswscale/swscale_internal.h
>>> +++ b/libswscale/swscale_internal.h
>>> @@ -345,8 +345,8 @@ typedef struct SwsContext {
>>>      DECLARE_ALIGNED(8, uint64_t, v_temp);
>>>      DECLARE_ALIGNED(8, uint64_t, y_temp);
>>>      int32_t  alpMmxFilter[4*MAX_FILTER_SIZE];
>>> -    DECLARE_ALIGNED(8, ptrdiff_t, uv_off_px);   ///< offset (in pixels) 
>>> between u and v planes
>>> -    DECLARE_ALIGNED(8, ptrdiff_t, uv_off_byte); ///< offset (in bytes) 
>>> between u and v planes
>>> +    DECLARE_ALIGNED(8, int64_t, uv_off_px);   ///< offset (in pixels) 
>>> between u and v planes
>>> +    DECLARE_ALIGNED(8, int64_t, uv_off_byte); ///< offset (in bytes) 
>>> between u and v planes
>>>      uint16_t dither16[8];
>>>      uint32_t dither32[8];
>>>
>>> --
>>
>> What is this supposed to fix, and why are those things declared with
>> extra alignment at all?  It makes no sense.
>
> It fixes ptrdiff_t being 4 bytes on x86-32, and then dither16 being at
> a different address. We hardcode the offset from dither16 somewhere
> for use in assembly.

Don't do that then.  If you must hardcode offsets, put those early in
the struct, before any variably sized elements.

> As for the alignment of int64_t, it may be a bug, but other pieces of
> sws use that also so I just adhered to a common style.

Adhering to the "common" "style" of swscale is not recommended.

-- 
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to