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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Sun, Mar 08, 2009 at 09:27:12PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Sun, Mar 08, 2009 at 08:24:43PM +0100, Reimar D?ffinger wrote:
>> >> On Sun, Mar 08, 2009 at 07:19:55PM +0100, Michael Niedermayer wrote:
>> >> > On Sun, Mar 08, 2009 at 09:38:33AM +0100, Reimar D?ffinger wrote:
>> >> > > 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 ?
>> >> 
>> >> We also need an implementation of it that works fine for asfcrypt.c.
>> >> Or in other words, coming up with a public API is not enough, we must
>> >> also come up with a way to actually use it within FFmpeg.
>> >> Which is not really a problem since I don't mind if the structure of
>> >> AVDES/AVRC4 is public and AVAES is always on the heap so far, it
>> >> just seems bad to be inconsistent with AVAES and to have no concept of
>> >> how to allocate AVAES on the stack (unless we decide there is never any
>> >> need to allocate them on the stack).
>> >
>> > what is the problem with DECLARE_ALIGNED() ?
>> 
>> That it doesn't work reliably for alignment greater than 8.
>
> So you suggest we should pick a more complex API that includes gcc bug
> workarounds?

It's not a gcc bug.  For better or worse, the C99 spec does not
include any mechanisms for enforcing a stronger alignment than
required by the declared type.  A compiler not having this as an
extension can hardly be considered a bug.

I suggest we pick an API that can actually be used from
standards-compliant code.  If that means making it more complicated,
so be it.

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