Reordering new API's that have a libctx, propq

[Matt Caswell]

On 21/09/2020 10:59, Matt Caswell wrote:
> 
> 
> On 16/09/2020 16:56, Matt Caswell wrote:
>>> "Adopt the coding style policy on function arguments as shown in chapter
>>> 6.1 of web PR 194 (commit 7b45b46d71f)"
> 
> This vote failed:
> 
> accepted:  no  (for: 2, against: 5, abstained: 2, not voted: 2)
> 
>>>
>>> "Adopt the coding style policy on extending existing functions as shown
>>> in chapter 6.2 of web PR 194 (commit 7b45b46d71f)"
> 
> 
> This vote is still in progress.

This vote has now also closed. It was passed:

accepted:  yes  (for: 5, against: 3, abstained: 2, not voted: 1)
> 
> Matt
> 
> 
>>>
>>> In the event that one vote passes but the other vote does not I will
>>> remove the section of text that did not pass from the PR and adjust
>>> chapter numbers accordingly.
>>>
>>> Matt
>>>
>>>>
>>>> Since we're not yet fully in agreement some compromises will have to be
>>>> made. I hope I've come up with something which isn't too abhorrent to
>>>> anyone.
>>>>
>>>> Please take a look.
>>>>
>>>> Matt
>>>>
>>>>
>>>> On 05/09/2020 04:48, SHANE LONTIS wrote:
>>>>>
>>>>>   PR #12778 reorders all the API’s of the form:
>>>>>
>>>>>
>>>>>   EVP_XX_fetch(libctx, algname, propq) 
>>>>>
>>>>>
>>>>>   So that the algorithm name appears first.. 
>>>>>
>>>>>
>>>>>   e.g: EVP_MD_fetch(digestname, libctx, propq);
>>>>>
>>>>> This now logically reads as 'search for this algorithm using these
>>>>> parameters’.
>>>>>
>>>>> The libctx, propq should always appear together as a pair of parameters.
>>>>> There are only a few places where only the libctx is needed, which means
>>>>> that if there is no propq it is likely to cause a bug in a fetch at some
>>>>> point. 
>>>>>
>>>>> This keeps the API’s more consistent with other existing XXX_with_libctx
>>>>> API’s that put the libctx, propq at the end of the parameter list..
>>>>> The exception to this rule is that callback(s) and their arguments occur
>>>>> after the libctx, propq..
>>>>>
>>>>> e.g:
>>>>> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
>>>>>     (const OSSL_STORE_LOADER *loader,
>>>>>      const char *uri, OPENSSL_CTX *libctx, const char *propq,
>>>>>      const UI_METHOD *ui_method, void *ui_data);
>>>>>
>>>>> An otc_hold was put on this.. Do we need to have a formal vote?
>>>>> This really needs to be sorted out soon so the API’s can be locked down
>>>>> for beta.
>>>>>
>>>>> --------
>>>>> Also discussed in a weekly meeting and numerous PR discussions was the
>>>>> removal of the long winded API’s ending with ‘with_libctx’
>>>>> e.g CMS_data_create_with_libctx
>>>>> The proposed renaming for this was to continue with the _ex notation..
>>>>> If there is an existing _ex name then it becomes _ex2, etc.
>>>>> There will most likely be additional parameters in the future for some
>>>>> API’s, so this notation would be more consistent with current API’s.
>>>>> Does this also need a vote?
>>>>>
>>>>> Regards,
>>>>> Shane
>>>>>
>>>>>