On Thu, Sep 12, 2013 at 04:10:37PM +0300, Martin Storsjö wrote: > On Thu, 12 Sep 2013, Diego Biurrun wrote: > >On Sun, Sep 08, 2013 at 08:09:17AM +0200, Luca Barbato wrote: > >>--- a/libavutil/mem.h > >>+++ b/libavutil/mem.h > >>@@ -100,14 +100,14 @@ av_alloc_size(1, 2) static inline void > >>*av_malloc_array(size_t nmemb, size_t siz > >> * Allocate or reallocate a block of memory. > >> * If ptr is NULL and size > 0, allocate a new block. If > >> * size is zero, free the memory block pointed to by ptr. > >>+ * @note Pointers provided by av_malloc family of functions cannot be > >>+ * passed to av_realloc(). > > > >Pointers originating from the av_malloc() family of functions must not > >be passed to av_realloc(). Just as with POSIX realloc(), behavior is > >undefined in that case; alignment requirements may not be fulfilled, > >crashes may occur. > > This omits a very vital point. If you just say "just as with POSIX > realloc", you are misssing the main point. If you compare av_malloc > and av_realloc to POSIX malloc and POSIX realloc, you don't have the > same issue. You can pass malloc() pointers to realloc(), but you > can't pass av_malloc() pointers to av_realloc(), since the former > can be implemented by (posix_)memalign. > > That is, the description needs to mention memalign at least in some > way. And mentioning that alignment requirements might not be kept is > just redundant and misleading from the actual point. > > What about: > > Pointers originating from the av_malloc() family of functions must > not be passed to av_realloc(). The former can be implemented using > memalign (or other functions), and there's no guarantee that > pointers from that function can be passed to realloc() at all - this > is undefined according to POSIX.
I like this. I'd just add that the consequence may be crashes to further caution people: .. according to POSIX and may crash with some libc implementations. Also, this should be @warning, not @note. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
