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

[Michael Niedermayer]

On Sun, Mar 08, 2009 at 10:42:36PM +0000, M?ns Rullg?rd wrote:
> 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.

that moves us back to uint8_t array vs uint64_t array vs making the struct
public.
... but then making the struct public is in no way better then using
DECLARE_ALIGNED

Iam in favor of uint64_t as this is the simplest now, uint8_t requires
realignment even with pure C.
if we ever want to use SSE* uint64_t can be realigned or the SSE accessed
parts can be malloced()


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

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/f88205e5/attachment.pgp>