Curl_strerror prefers POSIX over Windows system error codes

[jay]

I did this

Richard Alcock reported on the mailing list that Windows system error code ERROR_SHARING_VIOLATION (32) is mapped to error string "Broken pipe", and he correctly hypothesized that Curl_strerror interpreted the error code as POSIX error code EPIPE (32).

curl/lib/strerror.c

Lines 678 to 686 in 9cd755e

	/* 'sys_nerr' is the maximum errno number, it is not widely portable */
	if(err >= 0 && err < sys_nerr)
	strncpy(buf, strerror(err), max);
	else {
	if(!get_winsock_error(err, buf, max) &&
	!FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM, NULL, err,
	LANG_NEUTRAL, buf, (DWORD)max, NULL))
	msnprintf(buf, max, "Unknown error %d (%#x)", err, err);
	}

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,

1. 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.

2. 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).

curl/libcurl version

curl 7.67.0-DEV (i386-pc-win32) libcurl/7.67.0-DEV Schannel WinIDN
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug IDN IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI

operating system

Windows 7

Ref: 9c49824

[gvanem]

That is actually mostly correct because the calls we are recording the errors for are for POSIX /C runtime calls.

Seems I was to blame for that back in 2004:
https://curl.haxx.se/mail/lib-2004-04/0094.html

I'm amazed it has worked fine for so long.