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

[Michael Niedermayer]

On Mon, Oct 15, 2007 at 02:09:51PM +0200, Stefano Sabatini wrote:
> 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.

patch rejected it mixes too many unrelated changes
some pure spelling corrections some plain wrong


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071015/8f70efeb/attachment.pgp>