Re: Naming conventions

2020-07-06 Thread 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,

Re: Naming conventions

2020-07-06 Thread Richard Levitte
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

Re: Naming conventions

2020-07-03 Thread 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); > >

Re: Naming conventions

2020-06-29 Thread Richard Levitte
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

Re: Naming conventions

2020-06-19 Thread Richard Levitte
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

Re: Naming conventions

2020-06-19 Thread Tomas Mraz
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

Re: Naming conventions

2020-06-18 Thread Richard Levitte
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,

Re: Naming conventions

2020-06-18 Thread Tim Hudson
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

Re: Naming conventions

2020-06-18 Thread Matt Caswell
the complexity of the name change onto our downstream application maintainers. They will have all the confusion of different naming conventions within their application. It adds further complexity to our documentation. Either we only document the new forms (which is confusing when application mainta

Re: Naming conventions

2020-06-18 Thread Richard Levitte
inconsistent and, IMO, will cause > significant confusion for our users. Sure, but it counters the confusion with when to use FOO and when to use FOO_CTX as a prefix. You and I seem to be pretty clear on this, but I've seen enough questions on the matter to see the benefit with this change, even though i

Naming conventions

2020-06-18 Thread Matt Caswell
PRs #11996 and #11997 made some changes to the EVP_MAC and EVP_KDF API naming conventions. Specifically (in the MAC case) renaming: 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

C source file naming conventions

2019-02-22 Thread Matthias St. Pierre
Hi, there has been some discussion going on between Richard and me about the new naming style he introduced in pull request #8287. It would be nice to get some independent opinions from the team. Regards, Matthias See https://github.com/openssl/openssl/pull/8287#pullrequestreview-206706986