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. 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
