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

Reimar Döffinger Reimar.Doeffinger
Sun Mar 8 09:38:33 CET 2009


On Sun, Feb 08, 2009 at 02:18:30PM +0100, Reimar D?ffinger wrote:
> 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.

Is there a way we can go forwards with this or should we just give up on
making this public API.
Note that the reason to make it public API was the idea that libav*
should only use public API from each other so that people do not have to
remember to bump major also for non-public API changes (which may be
necessary to allow using two different major versions of a different
libav* lib - note this can be avoided by always bumping all major
versions together).




More information about the ffmpeg-devel mailing list