On 16/02/16 14:41, Anton Khirnov wrote:
> Quoting Diego Biurrun (2016-02-16 15:36:05)
>> On Tue, Feb 16, 2016 at 12:16:09PM +0000, Mark Thompson wrote:
>>> On 16/02/16 11:38, Diego Biurrun wrote:
>>>> On Mon, Feb 15, 2016 at 11:24:31PM +0000, Mark Thompson wrote:
>>>>> +static void vaapi_buffer_free(void *opaque, uint8_t *data)
>>>>> +{
>>>>> + AVHWFramesContext *hwfc = opaque;
>>>>> + AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
>>>>> + VASurfaceID surface_id;
>>>>> + VAStatus vas;
>>>>> +
>>>>> + surface_id = (VASurfaceID)(uintptr_t)data;
>>>>
>>>> Gah, why the double cast?
>>>
>>> Casting a pointer to a narrower integer type is dubious in C (can be
>>> undefined
>>> behaviour, even on unsigned integers). It shouldn't directly matter here
>>> because it originally came from the target type, but gcc does warn
>>> (VASurfaceID
>>> is unsigned int, so narrower given 64-bit pointers) and I'd prefer not to
>>> have
>>> the warning.
>>
>> This seems deeply suspicious, how does it even work at all?
>
> Why wouldn't it work? The value was originally a VASurfaceID, it just
> gets passed around as an uint8_t* pointer.
And indeed it does work perfectly on all architectures with sane pointers. I
was trying to clarify why the compiler correctly regards directly casting from a
pointer to a narrower integer type as possibly-undefined (C11 section 6.3.2.3
part 6) and therefore issues a warning for it. We then suppress that warning
with the double cast because we know more than the compiler - the range of the
type is definitely sufficient because the pointer always came from that type in
the first place.
> Also, exactly the same casts are used in other places in hwaccel code.
Where I copied them from. (Though I feel it is perfectly justifiable in
isolation, too.)
- Mark
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
