[FFmpeg-devel] [PATCH] install aes.h, des.h and rc4.h
Sun Mar 8 23:53:02 CET 2009
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
... but then making the struct public is in no way better then using
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel