[FFmpeg-devel] [PATCH] install aes.h, des.h and rc4.h

[Reimar Döffinger]

On Sun, Feb 08, 2009 at 01:42:47PM +0100, Michael Niedermayer wrote:
> On Sun, Feb 08, 2009 at 10:38:15AM +0100, Reimar D?ffinger wrote:
> > uint8_t aes_context[av_aes_size];
> > or
> > void *aes_context = malloc(av_aes_size);
> > or
> > void *aes_context = alloca(av_aes_size);
> > (using the first in asfcrypt.c, I assume we don't need to support
> > any compilers that do not support variable-size stack arrays?)
> > 
> > av_aes_init(aes_context, ...);
> 
> i think i like this most of what was suggested, what do you think about the
> alternative of:
> 
> const int av_aes_size = (sizeof(AVAES) + 7)/8;
> int av_aes_init(uint64_t *v, const uint8_t *key, int key_bits, int decrypt) {
>     AVAES *a = v;
>     ...
> }
> 
> uint64_t aes_context[av_aes_size];
> or
> uint64_t *aes_context = malloc(av_aes_size*8);
> or
> uint64_t *aes_context = alloca(av_aes_size*8);
> 
> also a typedef or struct could be used over uint64_t

Pro:
 - avoids a bit of a mess in av_aes_init etc.
Contra:
 - Will not help/waste more space/make even more of a mess if we ever want more than 8 bytes alignment
 - Slightly more complex when using malloc/alloca, av_aes_size not such
   a good name (size is rarely given as multiple of 8 bytes).
 - no idea if using uint64_t * instead of void * could create any
   (currently purely theoretical) aliasing issues, at least with
   compilers that try to optimize across files and static linking
 - needs a libavutil major version bump due to changed semantics of
   av_aes_size

As you might have expected I prefer my variant, the uint64_t seems a bit
like a hack for a very special case and I prefer more general solutions.
It is only a very minor preference though.

> > (using the first in asfcrypt.c, I assume we don't need to support
> > any compilers that do not support variable-size stack arrays?)
> 
> we have var sized arrays already in lav*

Good.

Greetings,
Reimar D?ffinger