CURL_GLOBAL_WIN32 should only control winsock #3313
Closed
Labels
Comments
jay
added a commit
to jay/curl
that referenced
this issue
Feb 16, 2019
- Change the behavior of win32_init so that the required initialization procedures are not affected by CURL_GLOBAL_WIN32 flag. libcurl via curl_global_init supports initializing for win32 with an optional flag CURL_GLOBAL_WIN32, which if omitted was meant to stop Winsock initialization. It did so internally by skipping win32_init() when that flag was set. Since then win32_init() has been expanded to include required initialization routines that are separate from Winsock and therefore must be called in all cases. This commit fixes it so that CURL_GLOBAL_WIN32 only controls the optional win32 initialization (which is Winsock initialization, according to our doc). The only users affected by this change are those that don't pass CURL_GLOBAL_WIN32 to curl_global_init. For them this commit removes the risk of a potential crash. Ref: curl#3573 Fixes curl#3313 Closes #xxxx
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
curl/lib/easy.c
Lines 226 to 230 in 1966771
CURL_GLOBAL_WIN32 is documented to control winsock initialization but controls win32_init which sounds (and is) more encompassing, as it does sspi initialization as well. I think we should split it off into win32_winsock_init for the flag and then a general win32_init that is always called, and we can move sspi init there.
This comes from my review of #3312, since it is only necessary to call QueryPerformanceFrequency once it makes more sense for us to do it at startup (like in win32_init) rather than every single time, and save the frequency in a global structure.
The text was updated successfully, but these errors were encountered: