strerror: honor Unicode API choice on Windows #6005
Conversation
| @@ -661,28 +662,19 @@ get_winapi_error(int err, char *buf, size_t buflen) | |||
|
|
|||
| *buf = '\0'; | |||
|
|
|||
| #ifdef _WIN32_WCE | |||
There was a problem hiding this comment.
There didn't seem to be any meaningful difference between the Windows CE version of this function and the regular Windows version, so I merged them.
|
Thanks! |
|
The winapi error function is used by the other strerror functions like Curl_strerror and aren't those functions used to output to the console in ANSI, like for example if German is the OS language and the build of curl is Unicode then wouldn't that now be returning UTF-8 instead of ANSI from this function, and wouldn't that cause messed up console output? |
|
@jay, I think you raise a good question. Previously, the use of If the main purpose of |
- Change get_winapi_error() to return the error string in the local codepage instead of UTF-8 encoding. Two weeks ago bed5f84 fixed get_winapi_error() to work on xbox, but it also changed the error string's encoding from local codepage to UTF-8. We return the local codepage version of the error string because if it is output to the user's terminal it will likely be with functions which expect the local codepage (eg fprintf, failf, infof). This is essentially a partial revert of bed5f84. The support for xbox remains but the error string is reverted back to local codepage. Ref: curl#6005 Closes #xxxx
- Change get_winapi_error() to return the error string in the local codepage instead of UTF-8 encoding. Two weeks ago bed5f84 fixed get_winapi_error() to work on xbox, but it also changed the error string's encoding from local codepage to UTF-8. We return the local codepage version of the error string because if it is output to the user's terminal it will likely be with functions which expect the local codepage (eg fprintf, failf, infof). This is essentially a partial revert of bed5f84. The support for xbox remains but the error string is reverted back to local codepage. Ref: #6005 Reviewed-by: Marcel Raad Closes #6065
The implementation of
Curl_strerroron Windows was explicitly calling the ANSI version of theFormatMessageWin32 API function, regardless of whether curl was being built to use the Unicode APIs. Some Windows-like platforms (e.g. Xbox) don't have the ANSI versions of these functions, so curl should honor the choice of using Unicode APIs instead.