Naming conventions

[Matt Caswell]

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). This is one of the areas of existing
quirkiness, so I'd be ok with leaving these names as they are.

But the fact that there is some strangeness in this area that we may be
willing to accept does not mean we should accept a totally new pattern
in other function names, i.e.

EVP_MAC_CTX_new -> EVP_MAC_new_ctx
EVP_MAC_CTX_free -> EVP_MAC_free_ctx
EVP_MAC_CTX_dup -> EVP_MAC_dup_ctx
EVP_MAC_CTX_mac -> EVP_MAC_get_ctx_mac
EVP_MAC_CTX_get_params -> EVP_MAC_get_ctx_params
EVP_MAC_CTX_set_params -> EVP_MAC_set_ctx_params

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.

In the interests of getting to some kind of decision on this I think a
simple OTC vote is probably in order. I already have a PR to revert this
(12186) which has an OTC hold on it. Therefore a simple vote to lift the
hold would be sufficient to at least make a decision for now.

My proposed vote text is:

"We should lift the OTC hold on PR12186 and continue the normal review
process"


Matt