On Thu, Mar 01, 2012 at 10:41:19AM -0800, Ronald S. Bultje wrote: > Hi, > > On Thu, Mar 1, 2012 at 10:39 AM, Kostya Shishkov > <[email protected]> wrote: > > On Thu, Mar 01, 2012 at 10:31:57AM -0800, Ronald S. Bultje wrote: > >> On Thu, Mar 1, 2012 at 10:26 AM, Kostya Shishkov > >> <[email protected]> wrote: > >> > On Thu, Mar 01, 2012 at 10:22:56AM -0800, Ronald S. Bultje wrote: > >> >> 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. (Also please > >> >> note that they're really always the same, so we're talking pure theory > >> >> bs here.) > >> > > >> > And someone else made a decision naming a library libtidsp. > >> > >> This discussion was had, sorry, I could only please 50%, I decided to > >> please the others. Reverting that will displease the other 50%. Please > >> move on. > >> > >> Now can we review the patch? > > > > Using intptr_t type for something that does _not_ contain actual pointer is > > misleading and that's why it's _not_ OK. > > I understand, but again, we had this discussion, it's 50/50 and > someone has to choose. We can't bikeshed over color forever, it was > causing actual crashes.
Then always pick ptrdiff_t over intptr_t: 0) it does what's needed 1) it has right definition and purpose (addressing and pointer arithmetics) 2) it's POSIX instead of XSI _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
