[flac-dev] [PATCH] for potential memory leaks

lvqcl lvqcl.mail at gmail.com
Sat Aug 22 03:03:26 PDT 2015


Erik de Castro Lopo wrote:

> I found a problem with this patch.
>
> Specifcally, where ever the patch tries to free() the old pointer
> where safe_realloc_mul_2op_() fails, can result in a double free().
>
> This is because, when safe_realloc_mul_2op_() has either of its size
> arguments equal to zero, will call realloc(ptr, 0) which according to
> the realloc manpage  is an implicit free() anyway.
>
> Working on a fix for this and re-visiting some of this realloc()
> stuff.
>

According to the following links --

http://www.cplusplus.com/reference/cstdlib/realloc/
http://stackoverflow.com/questions/6502077/malloc-and-realloc-functions
http://stackoverflow.com/questions/16759849/using-realloc-x-0-instead-of-free-and-using-malloc-with-length-of-a-string

-- the realloc behavior is different in C90 and C99: realloc(ptr,0) will
free ptr in C90 but the behaviour is implementation defined in C99.
So one shouldn't use realloc(ptr,0) instead of free(ptr).

For example: in metadata_object.c functions that call realloc(ptr, size)
check the size argument and never call realloc() if size==0.

What a caller function expects from  safe_realloc_mul_2op_(ptr, sz1, sz2)
if it calls it with the 2nd or 3rd argunent equal to 0?

And i have no idea what /* preserve POSIX realloc(ptr, 0) semantics */ comment means.


More information about the flac-dev mailing list