Typo intially in commit message, and PR Title ;)

Hmmm, hang on, the _PTR part isn't quite right. The intention of the OSSL_PARAM is that it should be possible for the structure to be constant, and for someone responding to a request to handle that...

My "hang on" meant that I'll make a change, so the approval came a little early 😉

Ok, reconfirmation needed

I'm currently reworking the documentation. OSSL_PARAM is getting a manual of its own, doc/man3/OSSL_PARAM.pod

Rework done for now, please have a look. I hope I've been able to make things clearer.

Added a NOTES section with some recommendation on how functions that treat the OSSL_PARAM array should behave

What can be simpler than treating C scalar types -- int, unsigned long, etc -- as their native types?

This is happening here and in #8320 native types will come across with a straight copy. They are passed as a pointer to the native type rather than the type itself.

You do run-time byte-order testing, and size/sign fiddling

Yes, but only if the sizes don't match. Pass an int in and ask for an int out and it is a straight copy, no fiddling. Checking is optimised out and I'm switching to using cpp instead.

If you put in an int, you should only get an int out. Don't automate widening, etc. C doesn't do that.

C does widen (and narrow):

int x;
long y;

y = x;    /* widening */
x = y;    /* narrowing */

Thanks for the C programming lesson :) It does that only in explicit assignments, and you often need a cast or the compiler will complain.

It only does it in ANSI C when a prototype is in-scope, and only for input parameters.

The OSSL_PARAM structure includes the type, isn't the best correspondence the ANSI C prototype case?

No, because it doesn't include the fully-specified type and will silently over/under flow if the width is wrong.

I've worked with the assumption that specific parameter will not change data type or size over time, i.e. if an object parameter "h" for a key in the algorithm "blargh" is specified to be a 64-bit unsigned integer, that will not change. Of course, actually knowing this is a matter of documentation with the provider that implements "blargh".

(side note: it should of course also be OK to specify that a certain parameter is an integer of arbitrary size)

I completely agree with that. Auto-resizing goes against that, and is error-prone.

side note: I keep mentioning "blargh" in my examples... I really should specify that algorithm, and it should be just as good as the name suggests 😉

Auto-resizing goes against that, and is error-prone.

That, however, isn't part of this PR

well, kinda, because this PR doesn't include enough support to "properly" handle scalars. And you told me to post here, not in #8320 :)

I told you to discuss OSSL_PARAM here. If you want to discuss @paulidale's added functions, #8320 is more appropriate.

this PR doesn't include enough support to "properly" handle scalars.

Dunno what you mean with "properly". Put a pointer to your scalar in param->buffer and you're done! (oh, and its size in param->buffer_size, of course)

i'll answer in my PR

Meanwhile, I rebased this on top of a fresh master, and squashed all fixup commits

Not only are all the pieces (caller, middle/roundezvous, implementer) all on the same host, they are all in the same address space. Previous discussion among the FIPS sponsors mailing list indicated that going off-process or off-host was not a goal.

I wonder if we may have a misunderstanding here? I can't recall this actually being discussed and indicated, except that we don't expect to see any other provider than the FIPS module and the default provider for 3.0.0 specifically. The stuff here, though, isn't just about 3.0.0, and I would rather stay clear of making too many assumptions about future provider modules.

Not only are all the pieces (caller, middle/roundezvous, implementer) all on the same host, they are all in the same address space. Previous discussion among the FIPS sponsors mailing list indicated that going off-process or off-host was not a goal.

I wonder if we may have a misunderstanding here? I can't recall this actually being discussed and indicated,

I don't recall having that discussion either. I do expect Provider authors to be able to do those sorts of things (even if we don't have any providers that do it in 3.0.0)

Merged.

4ca00f9 OpenSSL::Util::Pod: allow slashes in names
7753be7 Replumbing: Add include/openssl/core.h, initially with core types