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

[Michael Niedermayer]

On Sun, Feb 08, 2009 at 10:38:15AM +0100, Reimar D?ffinger wrote:
> On Sat, Feb 07, 2009 at 01:37:13PM +0100, Michael Niedermayer wrote:
> > On Sat, Feb 07, 2009 at 12:11:15PM +0100, Reimar D?ffinger wrote:
> > > On Fri, Feb 06, 2009 at 11:38:53PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Feb 06, 2009 at 11:18:57PM +0100, Reimar D?ffinger wrote:
> > > > > On Fri, Feb 06, 2009 at 10:33:00PM +0100, Michael Niedermayer wrote:
> > > > > > On Fri, Feb 06, 2009 at 09:53:16PM +0100, Reimar D?ffinger wrote:
> > > > > > > But maybe we can find a better solution.
> > > > > > > What about a
> > > > > > > void *av_alloca(uint8_t *);
> > > > > > > Usage would be
> > > > > > > uint8_t buffer[size + AV_ALLOCA_PADDING];
> > > > > > > struct AVAES *a = av_alloca(buffer);
> > > > > > > 
> > > > > > > Does that seem like it might make a good solution or does it have
> > > > > > > serious issues?
> > > > > > 
> > > > > > its not particularely pretty and something should be done to make it
> > > > > > less error prone, also no function call should happen just a macro
> > > > > >  or inline function
> > > > > 
> > > > > I did intend to make the function static inline.
> > > > > I think it will always ugly, though maybe something like (untested)
> > > > > #define AV_STACK_VAR(type, name, size) \
> > > > >     uint8_t name ff_alloca_##name##_buffer[size + 16]; \
> > > > >     type name = ff_alloca_##name##_buffer + ((-(long)ff_alloca_##name##_buffer - 1)&15) + 1;
> > > > > 
> > > > > fits your idea better?
> > > > 
> > > > type name = ff_alloca_##name##_buffer + ((-(long)ff_alloca_##name##_buffer)&15);
> > > > and +15 should be enough
> > > 
> > > I was too tired to think about it so I just copy-and-pasted the malloc
> > > stuff.
> > > So like this (note the ugly casting is to make sure it works with C++ as
> > > well, and I haven't tested it yet):
> > > Index: libavutil/mem.h
> > > ===================================================================
> > > --- libavutil/mem.h     (revision 16989)
> > > +++ libavutil/mem.h     (working copy)
> > > @@ -41,6 +41,17 @@
> > >  #endif
> > >  
> > >  /**
> > > + * Allocate data on the stack with sufficient alignment for all operations
> > > + * and assign it to the given variable.
> > > + * @param type type of the created variable, must be a pointer type
> > > + * @param name name of the created variable
> > > + * @param size Size in bytes for the memory block to be allocated.
> > > + */
> > > +#define AV_STACK_VAR(type, name, size) \
> > > +    uint8_t ff_alloca_##name##_buffer[size + 15]; \
> > > +    type name = (type)(void *)(ff_alloca_##name##_buffer + ((-(long)ff_alloca_##name##_buffer)&15));
> > > +
> > > +/**
> > >   * Allocates a block of \p size bytes with alignment suitable for all
> > >   * memory accesses (including vectors if available on the CPU).
> > >   * @param size Size in bytes for the memory block to be allocated.
> > 
> > iam not against this, though it isnt particularely pretty ...
> 
> Do you consider the following pretty:
> > const int av_aes_size = sizeof(AVAES) + 15;
> > int av_aes_init(void *v, const uint8_t *key, int key_bits, int decrypt) {
> > AVAES *a = (void *)(((uint8_t *)v) + ((-(long)ff_alloca_##name##_buffer)&15)));
> > // better make that an internal ALIGN_PTR macro? 15 -> 7 would be possible, too
> > ...
> > }
> 
> 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


> (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*

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/2bf394ca/attachment.pgp>