Naming conventions

[Matt Caswell]

On 06/07/2020 07:41, Richard Levitte wrote:
> On Fri, 03 Jul 2020 11:25:37 +0200,
> Matt Caswell wrote:
>> On 19/06/2020 08:15, Tomas Mraz wrote:
>>> to something like:
>>>
>>> int EVP_MacInit(EVP_MAC_CTX *ctx);
>>>       
>>> int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen);
>>>  
>>> int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize);
>>>
>>> or at least
>>>
>>> int EVP_MACInit(EVP_MAC_CTX *ctx);
>>>       
>>> int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen);
>>>  
>>> int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize);
>>>
>>> Should we do that? I hope for the sheer ugliness of the supposedly
>>> consistent names that we do not.
>>
>> This pattern is not universally used (as you mention the EVP_PKEY
>> API does something different).
> 
> Er, you've choose what you wanted to read, I suppose...  For fairly
> high level EVP APIs, the CamelCase form is actually quite consistent.
> For EVP_PKEY, we have them covering most if not all higher level
> usages:

I'm actually ok with using the CamelCase versions as well. But in the
interests of choosing my battles I'm for the moment just focusing on
getting us back to where we started.


> 
> EVP_Sign{Init, Update, Final}
> EVP_Verify{Init, Update, Final}
> EVP_Open{Init, Update, Final}
> EVP_Seal{Init, Update, Final}
> 
>> I remain strongly opposed to this renaming as I really don't think it
>> helps to do this sort of thing now. It just introduces significant
>> confusion without a long term strategy. We are too close to 3.0 beta1 to
>> embark on this journey now. I'm also not convinced that strategically
>> this is the right pattern to use.
> 
> What I hear from this is that 3.0 is the wrong time to introduce a new
> (and hopefully better) public API, that we should post-pone that to
> something like 4.0.  I can get along with that line of thought.

Ok. Good.

Matt