Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Richard Levitte
There are many red herrings in here, and I would argue that trying to be too uniform in the way you think about all functions may be harmful, because not all functions are classified the same. We cannot deny that many of our interfaces have an OOP flair. We may be programming in C, but we very ob

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Tim Hudson
On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote: > I'd rank the algorithm name as the most important, it really can't do > anything of value without it. > It also cannot do anything without knowing which libctx to use. Look at the implementation. Without the libctx there is no "from-where"

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Richard Levitte
Hi, so... "importance" quite obviously carries different meaning to different people. What I see below is the meaning "having the longest life span" or possibly "being the biggest and most powerful resource". I've a different interpretation of "importance". Looking at EVP_XXX_fetch(), it's pri

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Nicola Tuveri
On Sat, Sep 5, 2020, 14:01 Tim Hudson wrote: > On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote: > >> Or is your point that we are writing in C, all the arguments are >> positional, none is ever really optional, there is no difference between >> passing a `(void*) NULL` or a valid `(TYPE*) ptr

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Tim Hudson
On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote: > Or is your point that we are writing in C, all the arguments are > positional, none is ever really optional, there is no difference between > passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the value of a `TYPE > *` argument, so "importan

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Nicola Tuveri
On Sat, Sep 5, 2020, 12:13 Tim Hudson wrote: > On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote: > >> In most (if not all) cases in our functions, both libctx and propquery >> are optional arguments, as we have global defaults for them based on the >> loaded config file. >> As such, explicitly

OpenSSL is looking for a full time Administrator and Manager

2020-09-05 Thread Matt Caswell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The OpenSSL Management Committee are looking to hire a full time Administrator and Manager. Details of the role can be found here: https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ To apply please send your cover letter and res

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Tim Hudson
On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote: > In most (if not all) cases in our functions, both libctx and propquery are > optional arguments, as we have global defaults for them based on the loaded > config file. > As such, explicitly passing non-NULL libctx and propquery, is likely to b

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Nicola Tuveri
Thanks Tim for the writeup! I tend to agree with Tim's conclusions in general, but I fear the analysis here is missing an important premise that could influence the outcome of our decision. In most (if not all) cases in our functions, both libctx and propquery are optional arguments, as we have

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread SHANE LONTIS
Thanks for the writeup.. > My view is that the importance of arguments is what sets their order - and > that is why for the TYPE functions the TYPE pointer > comes first. We could have just as easily specified it as last or some other > order, but we didn’t. Isn’t that the order that the fetch

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Tim Hudson
I place the OTC hold because I don't believe we should be making parameter reordering decisions without actually having documented what approach we want to take so there is clear guidance. This was the position I expressed in the last face to face OTC meeting - that we need to write such things dow