Reordering new API's that have a libctx, propq

[Tim Hudson]

On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri <nic.tuv at gmail.com> 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 be
> an exceptional occurrence rather than the norm.
>

And that is where we have a conceptual difference, the libctx is *always* used.
If it is provided as a NULL parameter then it is a shortcut to make the
call to get the default or to get the already set one.
Conceptually it is always required for the function to operate.

And the conceptual issue is actually important here - all of these
functions require the libctx to do their work - if it is not available then
they are unable to do their work.
We just happen to have a default-if-NULL.

If C offered the ability to default a parameter if not provided (and many
languages offer that) I would expect we would be using it.
But it doesn't - we are coding in C.

So it is really where-is-what-this-function-needs-coming-from that actually
is the important thing - the source of the information the function needs
to make its choice.
It isn't which algorithm is being selected - the critical thing is from
which pool of algorithm implementations are we operating. The pool must be
specified (this is C code), but we have a default value.

And that is why I think the conceptual approach here is getting confused by
the arguments appearing to be optional - conceptually they are not - we
just have a defaulting mechanism and that isn't the same conceptually as
the arguments actually being optional.

Clearer?

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200905/5064146a/attachment.html>