Reordering new API's that have a libctx, propq

[Matt Caswell]

On 14/09/2020 12:46, Tim Hudson wrote:
> On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>     I must be misunderstanding your point because I don't follow your logic
>     at all.
> 
>     So this is the correct form according to my proposed policy:
> 
>     TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)
> 
> 
> 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?


>  
> 
>     > The PR should cover that context of how we name the variations of
>     > functions which add the OPENSSL_CTX reference.
> 
>     IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I
>     don't see why we need to special case OPENSSL_CTX in the policy. Its
>     written in a generic way an can be applied to the OPENSSL_CTX case.
> 
> 
> And that means renaming all the with_libctx to _ex which frankly I don't
> think makes a lot of sense to do. 

My understanding of the current consensus from previous discussions is
that most people feel differently to you on this. Maybe I'm wrong.


> Having a naming indicating OPENSSL_CTX added isn't a bad thing to do in
> my view.
> Collecting a whole pile of _ex functions and having to look at each one
> to figure out what the "extension" is does add additional burden for the
> user.
> There is a reason that _with_libctx was added rather than picking _ex as
> the function names - it clearly communicates then intent rather than be
> a generic extension-of-API naming.
> 
> 
>     IMO *the* most confusing thing would be to *change* an existing ordering
> 
>     (for example swap two existing parameters around). I see no problem with
>     adding new ones anywhere that's appropriate.
> 
> 
> Clearly we disagree on that - if you are making an extended version of a
> function and you aren't keeping the same existing parameter order (which
> you are not if you add or remove parameters which is the point I was
> making - the order isn't the same as the existing function because
> you've removed items - what you have is the order of whatever parameters
> remain in the extended function are the same - and that's a pretty
> pointless distinction to make - if you aren't simply adding additional
> items on the end you make for a change over mess and this I think we
> should be trying to avoid). My context there is for the users of the
> existing API.
> It becomes especially problematic if you have type equivalence when the
> order is changed around so there are no compiler warnings if the user
> hasn't picked up on reordering of parameters.

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.

Matt