[FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such
James Almer
jamrial at gmail.com
Fri Aug 25 18:12:15 EEST 2017
On 8/25/2017 11:39 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Aug 25, 2017 at 10:04 AM, James Almer <jamrial at gmail.com> wrote:
>
>> On 8/25/2017 8:10 AM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Thu, Aug 24, 2017 at 7:43 PM, James Almer <jamrial at gmail.com> wrote:
>>>
>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>> ---
>>>> The deprecation seems to have been imported from libav but never made
>>>> effective.
>>>
>>>
>>> Hm, but do we really want this function? Shouldn't all users be ported to
>>> the function this wraps?
>>
>> I don't know. The Doxy even acknowledges there's an alternative but
>> mentions its use case is apparently different, which is probably why
>> the deprecation wasn't made effective.
>>
>
> We should all acknowledge fully that there is a use case for
> memcpy_inverted(source, destination, size), yet libc does not define it. I
> don't know why. It's silly. I feel libc is being racist.
>
> Silliness aside, let's not have multiple APIs that do the same thing.
>
> If the function really needs to go, then the deprecated attribute should
>> be added to the header. And from that point the ~2 years deprecation
>> period starts.
>
>
> Sure, operationally I don't really care, as long as the end product is that
> it goes away.
Ok, patch dropped and a new one sent that effectively deprecates the
function.
>
> Fork nastiness aside, I feel that one thing Libav does have a much better
> handle on than us is API cleanliness.
>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
More information about the ffmpeg-devel
mailing list