Either one needs to be fixed. As they are taken via ... you can pass wrong functions and get extremely strange results, due to the C calling protocol allowing it. That kept me thinking for a while until I decided to grep the source.
IMO the prototype in the documentation is better, as RW locks, like the std::shared_mutex I was using, have different methods for shared and unshared locking. I can be coded around, just use the pair of the last successful lock that, but it is not trivial.
The text was updated successfully, but these errors were encountered:
https://curl.se/libcurl/c/CURLSHOPT_UNLOCKFUNC.html and https://curl.se/libcurl/c/CURLSHOPT_LOCKFUNC.html documentunlock_cb has having the same prototype as lockcb:
void unlockcb(CURL *handle, curl_lock_data data, curl_lock_access access, void *userptr);
void lockcb(CURL *handle, curl_lock_data data, curl_lock_access access, void *userptr);
But curl.h, in 7.82, defines them differently:
typedef void (*curl_lock_function)(CURL *handle,
curl_lock_data data,
curl_lock_access locktype,
void *userptr);
typedef void (*curl_unlock_function)(CURL *handle,
curl_lock_data data,
void *userptr);
Either one needs to be fixed. As they are taken via ... you can pass wrong functions and get extremely strange results, due to the C calling protocol allowing it. That kept me thinking for a while until I decided to grep the source.
IMO the prototype in the documentation is better, as RW locks, like the std::shared_mutex I was using, have different methods for shared and unshared locking. I can be coded around, just use the pair of the last successful lock that, but it is not trivial.
The text was updated successfully, but these errors were encountered: