On 8/25/2017 11:39 AM, Ronald S. Bultje wrote: > Hi, > > On Fri, Aug 25, 2017 at 10:04 AM, James Almer <jamr...@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 <jamr...@gmail.com> wrote: >>> >>>> Signed-off-by: James Almer <jamr...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
