[FFmpeg-devel] [PATCH] Doxygenate libavutil/mem.h

Stefano Sabatini stefano.sabatini-lala
Mon Oct 15 14:09:51 CEST 2007


On date Monday 2007-10-08 15:13:05 +0200, Stefano Sabatini encoded:
> On date Tuesday 2007-09-25 21:53:57 +0200, Stefano Sabatini encoded:
> > On date Sunday 2007-09-23 22:11:37 -0400, Rich Felker encoded:
> > > On Sun, Sep 23, 2007 at 09:47:44PM +0200, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > On Sat, Sep 22, 2007 at 03:18:16PM +0200, Stefano Sabatini wrote:
> > [...]
> > > > > I amended the previous patch eliminating in the av_realloc
> > > > > documentation all the references to other functions implementations,
> > > > > hope it is now more correct.
> > > > > 
> > [...]
> > > > > Index: libavutil/mem.h
> > > > > ===================================================================
> > > > > --- libavutil/mem.h	(revision 10549)
> > > > > +++ libavutil/mem.h	(working copy)
> > > > > @@ -33,26 +33,47 @@
> > > > >  #endif
> > > > >  
> > > > >  /**
> > > > > - * Memory allocation of size byte with alignment suitable for all
> > > > > + * Allocates a block of \p size bytes with alignment suitable for all
> > > > >   * memory accesses (including vectors if available on the
> > > > 
> > > > > - * CPU). av_malloc(0) must return a non NULL pointer.
> > > > > + * CPU). av_malloc(0) must return a non-NULL pointer.
> > > > 
> > > > i know this isnt new but its not true, av_malloc(0) will return NULL if
> > > > malloc(0) does in some cases
> > > 
> > > As rightly it should. Implementations which return non-NULL for
> > > zero-size mallocs are fundamentally stupid despite being valid.
> > > 
> > > > i dont know if its better to change the implementation or the docs but either
> > > > one must be changed ...
> > > 
> > > Change the docs. There's no reason to force libavutil to mimic stupid
> > > glibc behavior. Either it should force the sane behavior or leave it
> > > unspecified...
> > 
> > I left it unspecified, but at the same time I'm also stating:
> > @note av_malloc(0) return value is actually undefined, but future
> > versions might force it to be a non-NULL value.
> > 
> > Is this solution acceptable?
> > 
> > (Same note added to av_mallocz docs too.)
> > 
> > > > > - * av_realloc semantics (same as glibc): if ptr is NULL and size > 0,
> > > > > - * identical to malloc(size). If size is zero, it is identical to
> > > > > - * free(ptr) and NULL is returned.
> > > > > + * Allocates or reallocates a block of size \p size with alignment
> > > > > + * suitable for all memory accesses (including vectors if available on
> > > > > + * the CPU).
> > > > 
> > > > this is not true, the alignment will be as bad as what realloc() returns
> > > > currently, we could fix the implementaton (IIRC there where some patches)
> > > > but it would slow down av_realloc() considerably (>2x) if the realloc()
> > > > output isnt aligned
> > 
> > This time I learnt that I have to actually *read* the implementation
> > rather than just guess... 
> 
> [...]
> 
> Ping.

Sorry for insisting, just in the case the previous ones got lost.

Regards.
-- 
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doxygenate-mem-h-05.patch
Type: text/x-diff
Size: 2608 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071015/629c9b9d/attachment.patch>



More information about the ffmpeg-devel mailing list