openssl: Header file conflict code bug in windows
//reappear bug
#include <openssl/sha.h>
#include <openssl/aes.h>
#include <openssl/evp.h>
#ifndef CPPHTTPLIB_OPENSSL_SUPPORT
#define CPPHTTPLIB_OPENSSL_SUPPORT
#endif
#include <httplib.h>
the conflict between the above code and the httplib project reappear bug example
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 26 (19 by maintainers)
Commits related to this issue
- Move types.h #undefs for wincrypt.h compatibility + Always undef the symbols that may have been #define-d by wincrypt.h after the first inclusion of types.h to avoid errors from wincrypt.h symbol... — committed to samuel-lee-msft/openssl by samuel-lee-msft 2 years ago
- Move types.h #undefs for wincrypt.h compatibility + Always undef the symbols that may have been #define-d by wincrypt.h after the first inclusion of types.h to avoid errors from wincrypt.h symbol... — committed to samuel-lee-msft/openssl by samuel-lee-msft 2 years ago
- Move types.h #undefs for wincrypt.h compatibility + Always undef the symbols that may have been #define-d by wincrypt.h after the first inclusion of types.h to avoid errors from wincrypt.h symbol... — committed to t8m/openssl by samuel-lee-msft 2 years ago
- Move types.h #undefs for wincrypt.h compatibility + Always undef the symbols that may have been #define-d by wincrypt.h after the first inclusion of types.h to avoid errors from wincrypt.h symbol... — committed to openssl/openssl by samuel-lee-msft 2 years ago
- qfunctions_wince.h: Avoid https://github.com/openssl/openssl/issues/9981 by including <winsock2.h> — committed to datadiode/SfQtWebKit by datadiode a year ago
I think that httplib is an untypical case, because it has a header-only implementation which is intended to be included into a single C-module. For a general purpose HTTP library, I would consider it bad style or at least lack of abstraction to include implementation-specific headers like wincrypt.h or the openssl header. If at all, it should use forward declarations.
As soon as two third party libraries include mixed Wincrypt and OpenSSL headers, then it’s impossible to follow that guide. But as I said, it’s the third party library headers that need to be fixed imho.
It may help, or maybe not. I’m not sure whether it will work in all constellations. In any case, I am opposed to the name
WINCRYPT_OPENSSL_SYMBOL_COMPAT, it should be a more generic name likeWINCRYPT_[USE_]SYMBOL_NAMESPACEor something like that. You can mention OpenSSL as an example in the preceding comment, but please don’t make it part of the #define’s name.The short term solution seems like a reasonable approach. At least for now. I’m not sure if that would qualify as a bug fix eligible for backport to 3.0/1.1.1 (we normally try to avoid messing with the header files in a stable release)…I’m trying to think if there is any situation where doing that could break something
(2) sounds ideal if it can be arranged…but probably doesn’t help for quite a long time down the road when everyone has the new version of wincrypt.h.
Yes. From OpenSSL’s side we are trying to move to using the
OSSL_prefix for all new features - but we don’t do that if we’re just adding new things into a namespace we’ve already “claimed”. So, for example, new functions for doing X509 related things will start withX509_. Moving away from doing that would be very disruptive unfortunately 😦