gai_strerror is one of the Windows functions which behaves differently whether UNICODE is defined. See https://docs.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes Call gai_strerrorA so that we behave consistently in both modes. This fixes the build failure in https://chromium-review.googlesource.com/c/chromium/src/+/2613519. It also fixes a type error in the connect BIO (built but not used in Chromium), which wasn't noticed because ERR_add_error_data is a variadic function and untyped. (The type error won't go out of bounds because we're interpreting a NUL-terminated WCHAR* as a NUL-terminated char*. The string will be misinterpreted, but it still will be terminated either at the NUL WCHAR or, more likely, the upper zero byte of the first Latin-1 character in the string.) The ERR_add_error_data call raises the question of which of our char* strings are UTF-8 and which are the POSIX locale / Windows code page (when those are not also UTF-8). This CL doesn't address this and only fixes the character width error. Realistically, calling code tosses char* to printf so often that non-UTF-8 locales are probably a lost cause. (Although right now we do not transform any OS error strings, so tossing them to printf works fine. The outputs of functions like ASN1_STRING_to_UTF8, not so much.) Change-Id: Ie789730658829bde90022605ade2c86b8a65c3de Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44964 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>chromium-5359
parent
13da180506
commit
571c3e78bf
2 changed files with 10 additions and 1 deletions
Loading…
Reference in new issue