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

[James Almer]

On 8/29/2015 8:56 AM, Michael Niedermayer wrote:
> 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

Ok, I'll remove them from the release branch once it's created. We can then decide
what to do for the next.
Unless someone has a better idea of how to approach this.