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,
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
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);
>
>
This discussion seems to have gone stale.
As far as I can read the thread, there are three lines of thought at
play (in no special order):
- the API put forth in #11996 and #11997
- the API exemplified with EVP_MAC and EVP_KDF before #11996 and #11997
- the API exemplified by functions in
On Fri, 19 Jun 2020 09:15:22 +0200,
Tomas Mraz wrote:
> The problem is that there is not really fully consistent convention
> followed currently (even in 1.1.1, not counting the API additions in
> 3.0).
>
> For example if we would like to follow the convention _fully_ we would
> have to rename
On Fri, 2020-06-19 at 01:48 +1000, Tim Hudson wrote:
> We have a convention that we mostly follow. Adding new stuff with
> variations in the convention offers no benefit without also adjusting
> the rest of the API. Inconsistencies really do not assist any
> developer.
>
> Where APIs have been
On Thu, 18 Jun 2020 16:36:30 +0200,
Matt Caswell wrote:
> On 18/06/2020 13:03, Richard Levitte wrote:
> > As for not doing something piecemeal, I actually disagree, I see
> > benefit in more than just one person getting their hands dirty (plus
> > changing everything in one go may be overwhelming,
We have a convention that we mostly follow. Adding new stuff with
variations in the convention offers no benefit without also adjusting the
rest of the API. Inconsistencies really do not assist any developer.
Where APIs have been added that don't follow the conventions they should be
changed.
It
On 18/06/2020 13:03, Richard Levitte wrote:
>
> Okie, if we're going to start this discussion with taking a stand, I
> guess I'll declare that while I initially had the exact same concern,
> I now see this change in a positive light. This comment from #11997
> got me to change my mind:
>
>
On Thu, 18 Jun 2020 12:36:52 +0200,
Matt Caswell wrote:
>
> 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 ->
10 matches
Mail list logo
