Closed jasnell closed 3 years ago
I like the idea; but there are currently no OPENSSL_HAS_xxx
defines within the code. This would be the first, and would likely set a precedent. So, I want tread carefully here.
There really is no good way to detect if the QUIC API is available; there's no other #define to check against.
What about extending the 't' query values for const char *OPENSSL_info(int type);
or const char *OpenSSL_version(int type);
so that consuming code could ask for info on specific monikers for QUIC support. Existing implementations would not know the number and so return "not available" text.
https://www.openssl.org/docs/man1.1.1/man3/OpenSSL_version.html https://github.com/openssl/openssl/blob/a28d06f3e9cbc5594c7985c99a0c6bac5261ae67/include/openssl/crypto.h.in#L149
I see this as more of a compile-time vs run-time check. @jasnell ?
What about extending the 't' query values for const char OPENSSL_info(int type); or const char OpenSSL_version(int type); so that consuming code could ask for info on specific monikers for QUIC support. Existing implementations would not know the number and so return "not available" text.
Starting to like this idea a bit more. The #define can be used as a compile-time check, the call a run-time check.
See #4 (for 3.0.0, equivalent would be done for 1.1.1)
Yep, it's a compile time check. Essentially, for Node.js, we have folks that are going to be building Node.js using the upstream openssl/openssl and I want a very simple #ifdef
check in our code to determine whether we should even try. In those cases, they won't have the OPENSSL_NO_QUIC
define in place for us to key off.
@tmshort ... the approach in #4 could work also yes
See #6 for 1.1.1 version. Same #define, but new functions were introduced in 3.0...
Closing this in favor of #4 and #6.
Inverse of the OPENSSL_NO_QUIC, the OPENSSL_HAS_QUIC is only defined when QUIC is available.
This would also need to be applied to the 3.0.0 branch.
I have (as of today) signed and submitted the OpenSSL CLA.
Checklist