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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel