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

[Michael Niedermayer]

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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150829/94c674df/attachment.sig>