Diego Biurrun <[email protected]> wrote: >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.
Ok with me. // Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
