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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
