Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vtls: consistently use typedef names for OpenSSL structs #12439

Closed
wants to merge 1 commit into from

Conversation

davidben
Copy link
Contributor

@davidben davidben commented Dec 1, 2023

The foo_st names don't appear in OpenSSL public API documentation. The FOO typedefs are more common. This header was already referencing SSL_CTX via <openssl/ssl.h>. There is a comment about avoiding <openssl/x509v3.h>, but OpenSSL actually declares all the typedefs in <openssl/ossl_typ.h>, which is already included by <openssl/ssl.h> (and every other OpenSSL header), so just use that. Though I've included it just to be explicit.

(I'm also fairly sure including <openssl/ssl.h> already triggers the Schannel conflicts anyway. The comment was probably just out of date.)

The foo_st names don't appear in OpenSSL public API documentation. The
FOO typedefs are more common. This header was already referencing
SSL_CTX via <openssl/ssl.h>. There is a comment about avoiding
<openssl/x509v3.h>, but OpenSSL actually declares all the typedefs in
<openssl/ossl_typ.h>, which is already included by <openssl/ssl.h> (and
every other OpenSSL header), so just use that. Though I've included it
just to be explicit.

(I'm also fairly sure including <openssl/ssl.h> already triggers the
Schannel conflicts anyway. The comment was probably just out of date.)
@github-actions github-actions bot added the TLS label Dec 1, 2023
@bagder
Copy link
Member

bagder commented Dec 1, 2023

Thanks!

@bagder bagder closed this in 56791f3 Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

2 participants