On 10/13/2020 11:24 AM, Derek Buitenhuis wrote: > On 13/10/2020 15:19, Joakim Tjernlund wrote: >> For now just fixing av_malloc_max(0) will do, av_max_malloc2() etc. is >> beyond this patch. > > As Ronald mentioned, if you're going to fix the ABI/API, you should actually > fix every use of that ABI/API, not just the one you care about (0). > > So max values of 1-31 should also be handled.
I personally don't think there's anything to fix, or if there is, it's not this. For starters av_max_alloc() was never changed. It was how av_malloc() handled the max_alloc_size variable. And then, the old behavior was both buggy (0 to 31 equaling SIZE_MAX or slightly smaller) and undocumented. I could accept reverting it for the 4.3 branch for the sake of ABI compatibility, but after a sobump 0-31 should not wrap around or be replaced by something arbitrary like INT_MAX. Chromium already fixed their code by requesting a SIZE_MAX limit (meaning effectively unlimited), which is what they wanted to begin with, and others should follow. > > - Derek > _______________________________________________ > 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".
