[FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()

James Almer jamrial at gmail.com
Sat Aug 1 18:31:16 CEST 2015


On 01/08/15 7:15 AM, Nicolas George wrote:
> Le quartidi 14 thermidor, an CCXXIII, Reimar Döffinger a écrit :
>> If the goal is consistency, wouldn't an API like av_hash be the better
>> solution?
> 
> Hear, hear!
> 
> (Actually, when reading that discussion for the first time, I had not
> noticed it was about ciphers and not hashes, and my first reaction was
> "there is an unified API already".)
> 
>> And yes, on-stack allocations were desired, even though they make changes
>> to the structs hard...
> 
> Pointing the obvious: I very much doubt we ever need to change the struct
> used just for the implementation of a 30-years-old block cipher.

One example i can give that took advantage of the hidden nature of the struct
is ripemd. See aa70801aaf4038faaf673558c241fa19d5dcd181.
Admittedly one could blame this on my original design decision to reduce code
duplication (The object size grew considerably after that change), but in any
case had the struct not been opaque we would be stuck with a useless element
and its relevant ugly deprecation code for the next year or so, not to mention
how to handle the transform() function pointer.
Also, rc4 currently can't encrypt, only decrypt. No idea if adding encryption
functionality will require changes to the struct.

In any case, I have no preferences. I can push the alloc() function without
the deprecation code, or push both and decide later if the deprecation code is
kept or not. Which do you prefer?

> 
> This should be the guiding question: weight the potential hassle of a change
> in the struct versus the practical hassle of heap allocations.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 



More information about the ffmpeg-devel mailing list