Hi, On Jan 17, 2013 12:29 PM, "Justin Ruggles" <[email protected]> wrote: > > On 01/17/2013 11:28 AM, Ronald S. Bultje wrote: > > Hi, > > > > On Thu, Jan 17, 2013 at 2:15 AM, Reinhard Tartler <[email protected]> wrote: > >> On Thu, Jan 17, 2013 at 11:11 AM, Martin Storsjö <[email protected]> wrote: > >>> On Thu, 17 Jan 2013, Reinhard Tartler wrote: > >>> > >>>> On Wed, Jan 16, 2013 at 7:08 PM, Ronald S. Bultje <[email protected] > > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> On Jan 16, 2013 10:01 AM, "Justin Ruggles" <[email protected] > > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> On 01/16/2013 12:46 PM, Ronald S. Bultje wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Jan 16, 2013 9:43 AM, "Luca Barbato" <[email protected] > >>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 16/01/13 11:46, Luca Barbato wrote: > >>>>>>>>> > >>>>>>>>> From: "Ronald S. Bultje" <[email protected] > >>>>>>> > >>>>>>> <mailto:[email protected]>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Signed-off-by: Luca Barbato <[email protected] > >>>>>>> > >>>>>>> <mailto:[email protected]>> > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> Rebased and compile-tested on arm and powerpc. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Will be pushed in a while if nobody is against it. > >>>>>>> > >>>>>>> > >>>>>>> I had a question for Justin: the prefix is avpriv_, so is order in > >>>>>>> context part of abi? What about size? > >>>>>> > >>>>>> > >>>>>> I'm not completely sure. The header is not installed so it's not public, > >>>>>> so the only question I think is with mixing non-matching library > >>>>>> versions. > >>>>> > >>>>> > >>>> > >>>> avpriv matches av* and thus is part of the exported symbols. > >>>> Therefore, adding such a symbol warrants bumping minor (not major). > >>>> please do that before pushing. > >>>> > >>>> mixing non-matching library version becomes interesting when you bump > >>>> major. However, since all those symbols get proper symbol versions > >>>> attached nowadays, this is no problem either. > >>> > >>> > >>> It's not all that simple - the point here is that they're adding new fields > >>> in a private struct (which is used in the implicit private ABI between lavu > >>> and the others in this case) inbetween existing members. This means that an > >>> old lavc that tries to use members from the floatdsp context in a newer lavu > >>> will end up getting the wrong members. > >> > >> In that case, that's not private ABI. In fact, that term seems very > >> wrong, either it something is part for the exposed interface or it is > >> not. The difference here is that we do not expect applications and > >> applications outside of libav to inteface them. Which may be fine, but > >> hardly an excuse to sloppy on binary compatibility. If it breaks ABI, > >> and there is no way around it, we need to bump major. > >> > >>> If the members are added at the end, there shouldn't be too much of an issue > >>> though. > >> > >> If that works, then that's clearly preferable to bumping major! > > > > It changes size of the struct, thus embedding the struct in another > > struct (in another lib) will break when mixing library versions. To > > fix this, I believe we need a avpriv_alloc_floatdsp_context() function > > (or something else that is able to calculate the size of > > avfloatdspcontext at runtime, within libavutil). > > That's pretty much what I was thinking as well. We could even change the > init function to take AVFloatDSPContext ** and either allocate/init or > just re-init if already allocated.
That's definitely better, let's do that. Ronald
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
