On Thu, Mar 01, 2012 at 10:06:14PM +0100, Diego Biurrun wrote: > On Thu, Mar 01, 2012 at 08:23:00PM +0000, Måns Rullgård wrote: > > "Ronald S. Bultje" <[email protected]> writes: > > > 2012/3/1 Måns Rullgård <[email protected]>: > > >> Kostya Shishkov <[email protected]> writes: > > >>> On Thu, Mar 01, 2012 at 08:32:06AM -0800, Ronald S. Bultje wrote: > > >>>> > > >>>> On Thu, Feb 16, 2012 at 9:19 AM, Ronald S. Bultje <[email protected]> > > >>>> wrote: > > >>>> > On 64bit platforms with 32bit int, this means we won't have to sign- > > >>>> > extend the integer anymore. > > >>>> > --- > > >>>> > libavcodec/arm/vp8dsp_init_arm.c | 32 ++++---- > > >>>> > libavcodec/ppc/vp8dsp_altivec.c | 16 ++-- > > >>>> > libavcodec/vp8dsp.c | 44 +++++----- > > >>>> > libavcodec/vp8dsp.h | 38 +++++----- > > >>>> > libavcodec/x86/vp8dsp-init.c | 158 > > >>>> > +++++++++++++++++++------------------- > > >>>> > 5 files changed, 144 insertions(+), 144 deletions(-) > > >>>> > > >>>> Ping. > > >>> > > >>> is it still intptr? > > >> > > >> I still think these should be ptrdiff_t. > > > > > > See old thread, some people object to intptr_t and others object to > > > ptrdiff_t, for orthogonal reasons. Someone had to make a decision, > > > that person was me, and it is intptr_t. This is consistent with what > > > x264 does and thus probably a good long-term idea anyway. > > > > Two wrongs never make a right. > > I'll try to make an alternative proposal to hopefully make things move > forward: What about changing x264? We have developers working on both > projects after all...
Jason is fine with this, so go ahead, guys :) Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
