[FFmpeg-devel] [PATCH] Fix function parameters for rgb48 to YV12 functions.

[Måns Rullgård]

Ramiro Polla <ramiro.polla at gmail.com> writes:

> Index: libavutil/common.h
> ===================================================================
> --- libavutil/common.h	(revision 21602)
> +++ libavutil/common.h	(working copy)
> @@ -337,6 +337,28 @@
>  
>  #include "mem.h"
>  
> +/**
> + * The array_index type is the same width as the registers the architecture
> + * uses to index arrays,

What does that mean?  Indexing arrays is not a concept that exists at
the machine level.

>                           which for example simplifies calculations without
> + * requiring a 32->64 bit conversion. In this example code compilers will use
> + * width as both the counter and the array index itself, instead of creating
> + * one more variable.
> + * @code
> + * func(int *dst, int *src, array_index width) {
> + *     int i;
> + *     for (i = 0; i < width; i++)
> + *         dst[i] = src[2*i];
> + * }

Regardless of the type, the compiler is just as likely to turn that
into something resembling this (yes, I've seen them do it):

    while (width-- > 0) {
        *dst++ = *src;
        src += 2;
    }

Now there's no indexing at all, and no reason for anything to have a
special type.  For all you know it could even get worse.  In fact, on
x86_64 insisting on a 64-bit type there means anything touching it
will need a 64-bit prefix thus increasing the code size for no good
reason at all.

> + * @endcode
> + */
> +#if   ARCH_X86_64
> +typedef int64_t array_index;
> +#elif ARCH_X86_32
> +typedef int32_t array_index;
> +#else
> +typedef int     array_index;
> +#endif

Under no circumstance will I allow this in a public header.

-- 
M?ns Rullg?rd
mans at mansr.com