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

[Michael Niedermayer]

On Sun, Feb 08, 2009 at 01:00:13AM +0100, Reimar D?ffinger wrote:
> On Sun, Feb 08, 2009 at 01:20:05AM +0100, Michael Niedermayer wrote:
> > On Sat, Feb 07, 2009 at 02:07:36PM +0100, Reimar D?ffinger wrote:
> > > Well, I'd happily take a pretty solution if you can offer one.
> > 
> > > But making the AES API public while the only way to use it is a way you
> > > wouldn't accept in libavformat seems pointless to me.
> > > I don't care, I wasn't the one who requested to move everything to a
> > > public API.
> > 
> > i really dont see the problem, malloc() can be used to allocate a struct,
> 
> You objected to the patch that used av_malloc, so obviously it is not
> quite as simple.

A user app can use *malloc() or course ...
Iam against it in lav because it isnt really needed.


> 
> > alloca() can as well
> 
> alloca is not portable

it might be supported on all systems a user app cares about


> 
> > so can a uint64_t array.
> 
> and all of these do not allow to use SSE or similar in future
> implementations. Not that I have any plans, but you seemed to consider
> simplifying future improvements important enough to prefer an
> inconvenient API over having to bump the major version.
> I very much understand your concerns, but for my taste they feel a bit
> much like "keeping it extensible for the sake of it", or short
> "overengineered".

sorry but i think this applies to your solutions much more than mine.

My goal is primarely to have a simple system (your suggestions are not
simple they rather are well overengineered)
if there are 3 reasons why we might have to bump the major version then
a API that doesnt need to bump the version in 2 of these is better than
one that always needs to bump.

and if then a messy and complex solution that is said to solve the 3rd too
is presened like vastly supperior without ever bothering to proof that the
3rd variant really needs a bump in the other cases i cant help but must say
your solutions feel alot like the problems are constructed to justify the
mess not the mess constructed to solve a problem.
And i must admit i feel the same in case of your rant about localtime()

passing its output to another thread and the original one exiting ...
people dont do this ...


so please first explain me what problem my current code really has,
how likely this is going to hit us in reality and how bad the consequences
would be.

IMHO, if we suddenly require more alignment than the original publication
of the api did. the functions themselfs could do the align and require a
few bytes more, this is exactly identical to your suggestion but factorizes
the mess away from the user app and is fully within the current API/ABI.
Also the extra code would only become required once there actually is a
need for more alignment ...

ahh and sorry if i sounded rude, it wasnt intended, i just think my
current code (with better documentation of the alignment) is better than
what you suggested

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/a77ed949/attachment.pgp>