On 11/3/2020 10:19 AM, Joakim Tjernlund wrote: > On Tue, 2020-11-03 at 10:05 -0300, James Almer wrote: >> >> On 11/3/2020 9:12 AM, Anton Khirnov wrote: >>> Quoting Joakim Tjernlund (2020-11-03 12:39:53) >>>> Pretty please ? >>> >>> ok, would people who are strongly against this patch please raise their >>> hands. >> >> Would applying this to master now (backporting it to 4.3 too) and then >> reverting it at the time of the major bump work? The idea here if i >> understood correctly is to keep ABI compatibility with software that was >> linked to <= 4.2 and can't be recompiled to replace av_malloc_max(0) >> calls with av_malloc_max(SIZE_MAX), right? > > Right. > >> Because requesting for example a limit of 31 resulting in av_malloc() >> having practically no limit is pretty silly and should have never happened. > > I first did the the patch for only special handling 0 but this list asked me > to > be precise so I changed it.
I know, I'm talking about ensuring it's removed again after a soname bump precisely because it's absurd. If we ultimately decide to make 4.3 ABI compatible with 4.2 as far as av_malloc() goes, then it needs to handle 0-31 the same way. > >> >>> Personally I'm ok with pushing this, even though it's ugly. Then again >>> the vey existence of av_malloc_max is ugly and it should be deprecated >>> IMO. >> >> Is there any real world use examples of it (outside of 0/SIZE_MAX to >> disable the default INT_MAX limit)? Maybe it's superfluous and can be >> removed just fine. >> > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
