param: Param add a modified indicator to OSSL_PARAM. #11588
Conversation
doc/man3/OSSL_PARAM_int.pod
Outdated
Show resolved
Hide resolved
|
I wonder if it would be better to not document how the modification detection works. |
doc/man3/OSSL_PARAM_int.pod
Outdated
Show resolved
Hide resolved
|
I'm wondering if you shouldn't mention what the value of |
Why? |
To give us some flexibility to change it without incurring breakage. I can't guarantee that it will never need changing. By not spelling it out, we can change it because the helper functions and macros hide the details. |
Would it be more future proof to have a separate flag variable to track the state of an OSSL_PARAM? |
Yes, but it was shot down in the past. Stealing a bit from the type field would be another possibility (although this would be far too invasive to consider now). OSSL_PARAM is a public structure and we want to keep it plain and simple. A version number and some flags wouldn't go astray but... |
... and that's exactly the reason to document the unmodified trick |
|
Should this be also cleaning up where we already use the return_size in this fashion. There are quite a few of them. |
We should clean them up. I'd prefer to get this in and to then address the other uses. I didn't release that such uses were widespread. |
They aren't yet.
|
|
|
||
| void OSSL_PARAM_set_unmodified(OSSL_PARAM *p) | ||
| { | ||
| if (p != NULL) |
richsalz
Apr 21, 2020
Contributor
dislike the NULL checks here and above FWIW.
dislike the NULL checks here and above FWIW.
|
Since the structure is public, and since the define's are public, and since openssl considers the contents of the header files, and not just the documentation of them, to be part of the API/ABI, might as well document what things currently do. |
|
Merged to master, thanks. |
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #11588)
I thought I remembered the stance being a bit more subtle than that; do you have a pointer handy ("no" is a fine answer)? |
|
Sorry, I don't. Perhaps @t-j-h might reply here, since he was an advocate of that view. |
|
Generally speaking, we consider the public headers to define the API. However, I would argue that some of those headers or APIs have become public by accident, so it's possible to justify that some of them should stop (see parts of the CONF API that was recently made unpublic). OSSL_PARAM is intentionally a public structure, however, and very much part of the libcrypto<->provider interface, so it's safe to say that it should be considered part of the public API. |
|
OSSL_PARAM is intentionally a public structure, however, and very much part of the libcrypto<->provider interface, so it's safe to say that it should be considered part of the public API.
It's not because it's used for the interface between libcrypto and
the providers, that it should also be used in the interface
between the application and the libcrypto.
|
Using the return_size field as a sentinel for change detection.