[FFmpeg-devel] [PATCH v4] Unbreak av_malloc_max(0) API/ABI

[James Almer]

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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>