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

[Michael Niedermayer]

On Sun, Mar 08, 2009 at 09:38:33AM +0100, Reimar D?ffinger wrote:
> 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.

Where was the problem with just saying in the docs that the struct must be
aligned so that all user level instructions on the platform can access it.
Or for portable applications align by 16 byte
or something similar
?


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

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20090308/d32609c7/attachment.pgp>