<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><h1 class="mb-2 gh-header-title lh-condensed"><span class="js-issue-title" style="font-size: 12px; font-weight: normal;">PR </span><span style="font-size: 12px; font-weight: normal;" class="">#12778 reorders all the API’s of the form:</span></h1><h1 class="mb-2 gh-header-title lh-condensed"><span style="font-size: 12px; font-weight: normal;" class="">EVP_XX_fetch(libctx, algname, propq) </span></h1><h1 class="mb-2 gh-header-title lh-condensed"><span style="font-size: 12px; font-weight: normal;" class="">So that the algorithm name appears first.. </span></h1><h1 class="mb-2 gh-header-title lh-condensed"><span style="font-size: 12px; font-weight: normal;" class="">e.g: EVP_MD_fetch(digestname, libctx, propq);</span></h1><span class="">This now logically reads as 'search for this algorithm using these parameters’.<br class=""><br class=""></span><span class="">The libctx, propq should always appear together as a pair of parameters.</span><div class=""><span class="">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. <br class=""><br class=""></span><div class="">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..</div><div class="">The exception to this rule is that callback(s) and their arguments occur after the libctx, propq..</div><div class=""><br class=""></div><div class="">e.g:</div><div class=""><div class="">typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)</div><div class=""> (const OSSL_STORE_LOADER *loader,</div><div class=""> const char *uri, OPENSSL_CTX *libctx, const char *propq,</div><div class=""> const UI_METHOD *ui_method, void *ui_data);</div></div><div class=""><br class=""></div><div class="">An otc_hold was put on this.. Do we need to have a formal vote?</div><div class="">This really needs to be sorted out soon so the API’s can be locked down for beta.</div><div class=""><div class=""><br class=""></div></div><div class="">--------</div><div class="">Also discussed in a weekly meeting and numerous PR discussions was the removal of the long winded API’s ending with ‘with_libctx’</div><div class="">e.g CMS_data_create_with_libctx</div><div class="">The proposed renaming for this was to continue with the _ex notation.. If there is an existing _ex name then it becomes _ex2, etc.</div><div class="">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.</div><div class="">Does this also need a vote?</div><div class=""><br class=""></div><div class="">Regards,</div>Shane<br class=""><div class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br class=""></div>
</div>
<br class=""></div></body></html>