Yes, strings and octets are coming in another PR.
They need to deal with the _PTR versions transparently.

We should also address the question as to which types exactly we want to include. I've only got the thirty two and sixty four bit ones here plus size_t. Do we need sixteen bit integers or floats?

Do we need sixteen bit integers or floats?

A point: this PR doesn't have to be feature complete. If it turns out later that we want those, it would be fairly easy to add.

WIthout narrowing, adding them after 3.0 could be problematic.
I'm happy to leave them out for the moment.
I'm also happy to add the narrower types in here using casts.

I'm looking at all this, and am thinking of a use case that I think will be fairly common... I'll write it raw form for now (macros lacking).

So the case here is that an application wants to use some provider that's unknown to us, offering the asymmetric algorithm "blargh", and wants to find out the public parameters for some key (i.e. the numbers, like RSA's n and e), using some EVP_PKEY function that doesn't exist yet (totally top of my mind). The type and size of these parameters are documented with the provider, so the application author know what they're dealing with.

    int32_t blargh_f = 0;
    double blargh_g = 0.0;
    unsigned char blargh_p1[4096 / 8];
    unsigned char blargh_p2[4096 / 8];
    const OSSL_PARAM params[] = {
        /* |f| is documented to be a 32-bit signed integer.  No need for a return size */
        { "f", OSSL_PARAM_INTEGER, &blargh_f, sizeof(blargh_f), NULL },
        /* |g| is documented to be a double.  No need for a return size */
        { "g", OSSL_PARAM_REAL, &blargh_g, sizeof(blargh_g), NULL),
        /* |p1| and |p2| are documented to be arbitrarily large unsigned integers, maximum 4096 bits */
        { "p1", OSSL_PARAM_UNSIGNED_INTEGER, &blargh_p1, sizeof(blargh_p1), &blargh_p1_l },
        { "p2", OSSL_PARAM_UNSIGNED_INTEGER, &blargh_p2, sizeof(blargh_p2), &blargh_p2_l },
        { 0 }
    };

    if (!EVP_PKEY_get_public_params(pkey, params))
        goto err;
    /*
     * do whatever with the parameters
     * among others, blargh_p1 and blargh_p2 should be imported into whatever MP type
     * the application writer prefers
     */

I have a hard time seeing how this is supported in this PR, which seems to be preoccupied with more dynamic aspects.

Comments?

I'm unsure what you're getting at. The macros will handle the first two entries fine. The final two aren't supported. At least at the moment.

The macros will handle the first two entries fine.

Cool. I was unsure how to understand this PR, so thanks for confirming.

The final two aren't supported. At least at the moment.

(emphasis mine) Ok, I'll try to be patient 😉

There is a fair bit more to do. Strings and octets need supporting functions and (maybe) macros. I'd like the _PTR variations to be hidden from users. BIGNUMs also need some hiding and they'll need the length passed back (which are the missing cases above).

I also need to do some BIGNUM test cases and confirm that the integer functions are adequately covered by the existing tests.

I'm running out of time...

I'd like the _PTR variations to be hidden from users.

I don't think that's a good idea. There are some very crucial differences between the _PTR and non-_PTR variations, such as having to provide a separate (larger than pointer size) buffer to transfer the value or not, especially for getting parameters.

It's possible that the _PTR variation turns out to be a bad idea, if it turns out to be too difficult to handle. Removing it means a lot more copying of constants, but I'm unsure how many of those we'll see, or rather how often such values will be retrieved, and if the optimization is worth the while.

Let's see if I can come up with a nice _PTR neutral flavour. I'm not sure it is possible but I'd like to at least try.

I'm not sure it is possible but I'd like to at least try.

Trying is good... I have my doubts, but please never let that stop you from trying. Worst case, we might both be pleasantly surprised 😉

It is unfortunate that so much effort has been spent on re-doing this since #8377 starts from a cleaner space.

The bulk of the changes took about half an hour :) That's roughly the time between my comment about prototyping a middle ground approach and the first push.

I've pulled OSSL_PARAM_locate out as a separate API and not called it from the get/set functions.
Refer to #8399 for the rationale behind this.

The BIGNUM test is failing. I'll fix.

Closing in favour if #8400 which includes a pile more functionality.