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

[James Almer]

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.