[FFmpeg-devel] [PATCH v5] lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data
Mats Peterson
matsp888 at yahoo.com
Mon Jan 11 07:05:19 CET 2016
On 01/11/2016 01:46 AM, Michael Niedermayer wrote:
> On Sun, Jan 10, 2016 at 04:04:47AM +0100, Mats Peterson wrote:
>> How about this one, Michael? Rather than using the obviously
>> dangerous av_realloc() it uses av_malloc() to allocate new memory
>> for the private data, then copies the private data to it, frees the
>> pointer to the original private data, and finally sets
>> track->codec->priv_data to the newly allocated memory.
>
> that documentation is misleading, av_malloc() is if one is really
> pedantic not safe to be passed to av_free or av_realloc()
> if one isnt pedantic it safe to be passed to both
>
> but of course theres nothing wrong with seperating them if you want
> to seperate them in your code. Theres a small theretical chance that
> some future platform will not work with mixed aligned memory and
> realloc but would be able to mix both with free()
>
> patch applied
>
> thanks
>
Well, I think I understand what you mean now, at least when it comes to
av_malloc() and av_free(). From the manpage for memalign():
"POSIX requires that memory obtained from posix_memalign() can be freed
using free(3). Some systems provide no way to reclaim memory allocated
with memalign() or valloc() (because one can only pass to free(3) a
pointer gotten from malloc(3), while, for example, memalign() would call
malloc(3) and then align the obtained value). The glibc implementation
allows memory obtained from any of these functions to be reclaimed with
free(3)."
Mats
More information about the ffmpeg-devel
mailing list