Reordering new API's that have a libctx, propq

[Matt Caswell]

On 14/09/2020 13:14, Tim Hudson wrote:
> On Mon, Sep 14, 2020 at 9:52 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>     > And that is the point - this is not how the existing CTX functions
>     work
>     > (ignoring the OPENSSL_CTX stuff).
> 
>     Do you have some concrete examples of existing functions that don't work
>     this way?
> 
> 
> SSL_new()
> BIO_new_ssl()
> BIO_new_ssl_connect()

All of these three are consistent with my proposed policy.

The policy says:

"the key argument that identifies the thing be constructed should be
placed first (if such an argument exists)"

The parenthetical comes into play here "if such an argument exists". It
doesn't exist in any of these three cases and therefore this part
doesn't apply. In all cases the arguments are a single argument and so
trivially agree with the ordering rules.


> BIO_new_bio_pair()

This one is a slight oddity in that it doesn't create just one object
but two. I'm not aware of anywhere else where we do this, but even if we
do I don't think it is a common pattern, so I don't feel the need to
base our future policy on this precedent.


> etc
> 
> And all the existing method using functions which are also factories.
> 
> But I get the point - if there is only one argument is it logically
> coming first or last - obviously it can be seen both ways.
> 
>     IMO, we absolutely MUST have the ability to delete parameters (for
>     example ENGINEs). If we can do that, then I don't see why we can't add
>     parameters.
> 
> 
> No - that doesn't follow. It is perfectly reasonable to have an ENGINE
> typedef that remains and is passed as NULL as usual - and in fact most
> of the top-level ENGINE stuff handles NULL as meaning no engine usage so
> that would remain consistent. There is no absolute requirement to
> delete a parameter for this or other purposes. If you want to reorder
> parameters I would argue it should be a new function name and not an _ex
> version.

I disagree with you on this.

Matt