Richard Alcock reported on the mailing list that Windows system error codeERROR_SHARING_VIOLATION (32) is mapped to error string "Broken pipe", and he correctly hypothesized that Curl_strerror interpreted the error code as POSIX error codeEPIPE (32).
The issue is Curl_strerror on Windows prefers POSIX error strings over Windows system error strings. That is actually mostly correct because the calls we are recording the errors for are for POSIX /C runtime calls. However in the reported example the error code is from a Windows API call and recorded using GetLastError() (ie get the last windows system error code) so one would expect to get the mapped Windows system error string in that case.
I expected the following
2 options come to mind,
Add a separate function like Curl_winsys_error that handles just winapi errors, for when we know for certain the error code we're passing in is definitely from windows system.
Change the CreateFile/ReadFile calls to fopen/fread.
Windows system error codes that overlap (the ones less than 50) look to be file related except for ERROR_NOT_ENOUGH_MEMORY (8).
- In all code call Curl_winapi_strerror instead of Curl_strerror when
the error code is known to be from Windows GetLastError.
Curl_strerror prefers CRT error codes (errno) over Windows API error
codes (GetLastError) when the two overlap. When we know the error code
is from GetLastError it is more accurate to prefer the Windows API error
Reported-by: Richard Alcock