Hi, 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: >>> Hi, >>> >>> 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. (Also please note that they're really always the same, so we're talking pure theory bs here.) Also note that me forcing that earlier patch through fixed a real bug (rv40 failing on Win64), since int was not sign/zero-extended, thus causing a fail when reading as a function argument from stack (which happens on Win64). Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
