[FFmpeg-devel] [PATCH 1/4] lavu: add simple array implementation

[Michael Niedermayer]

On Mon, Mar 03, 2014 at 11:55:24AM +0100, wm4 wrote:
> On Mon, 3 Mar 2014 11:33:20 +0100
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > On Mon, Mar 03, 2014 at 11:00:18AM +0100, Lukasz M wrote:
> > > W dniu poniedziałek, 3 marca 2014 Michael Niedermayer <michaelni at gmx.at>
> > > napisał(a):
> > > 
> > > > On Mon, Mar 03, 2014 at 01:59:43AM +0100, Lukasz Marek wrote:
> > > > >
> > > > > >You're adding it to lavu, and it's not marked as internal/experimental.
> > > > If
> > > > > >it stinks or needs 3 API updates or re-implementations, the old cruft
> > > > > >sticks around for years to come.
> > > > >
> > > > > Can you precise how to mark it? I added it as public, but don't
> > > > > understand how can i make it experimental.
> > > > >
> > > >
> > > > > >That's why we now have 2 (and with yours, soon 3) array implementations.
> > > > > >Can we stick to one? At least java uses the same API for all its
> > > > array/list
> > > > > >things.
> > > > >
> > > > > The existing two doesn't allow to free "objects" with allocated
> > > > > pointers inside. If you fix them then you have 4. I really think it
> > > > > is better to have one common for wide range of use cases. I can
> > > > > refactor existing code to use mine if accepted.
> > > >
> > > > if i have an array of "object" with pointers inside them and want
> > > > to free them id do
> > > >
> > > > for(i=0; i<arraysize; i++)
> > > >     my_free(my_array + i);
> > > >
> > > > that needs no API beyond ANSI/ISO C
> > > > what am i missing ?
> > > >
> > > 
> > > nothing. existing array impl is not so smart to do that on memory
> > > allocation fail AFAIR.
> > 
> > maybe it could be solved with something like
> > int av_dynarray_add_nofree(...)
> > 
> > which would not free the array on failure but return an error code
> > and leave deallocation (if needed) to the caller
> 
> Freeing the whole array just because adding one element failed sounds
> quite idiotic. (Though I guess it's ok for certain use cases, like
> initialization.) But apparently these are the existing semantics. Adding
> the function you propose sounds like a good idea.
> 

> Even with the av_dynarray_add() semantics, one could just pass a free
> callback to the function, instead of needing an array struct.

yes, i was thinking of that too but i couldnt decide what arguments
the callback would need. It might need an opaque / context pointer
possibly but then one needs to pass that too to av_dynarray_add
so i ended up suggesting what i did suggest ...


> 
> By the way, av_dynarray_add() seems to violate strict aliasing rules...

not sure if what iam thinking of is what you meant but
ISO/ANSI C allows char types to alias anything


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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140303/bdbdef98/attachment.asc>