On Sat, Aug 29, 2015 at 02:54:06AM -0300, James Almer wrote: > 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 think if theres no consens on deprecating it then its better not to deprecate in the release > 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
