On 8/1/2015 1:31 PM, James Almer wrote: > 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,
Since this set was merged from libav as-is and we're about to make a 2.8 release i want to know if we should abort the deprecations right now before the release, or leave them alone and decide later on. I tried updating the rtmp code to dynamically allocate the structs and that not only meant some considerable changes to the functions in order to propagate allocation failure errors, but i also got some odd behavior with the test served i tried. I could have done something wrong, though. Why is it a good idea to decide before release? Because if we get a release out there with the deprecations in place, we would then have (or at least it would be proper) to inform users with a line in APIChanges about the deprecation being aborted if that's what we choose to do. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel