Probably worth benchmarking this, given it slows down every process
startup.
Change-Id: I603c79a445203f87e26fa23d9afc4450688f2929
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45245
Reviewed-by: Adam Langley <agl@google.com>
Our use-case for this does not require optimisation at the current time,
so a clean C implementation is fine.
Change-Id: I8f29572c33e8dbcc37961c099c71c14aafc8d0a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45164
Reviewed-by: David Benjamin <davidben@google.com>
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>
This fixes a couple issues:
- Which libraries to use should be based on WIN32, not MSVC.
- Windows libraries can be specified by #pragma comment lines in the
source or by build dependencies. We specified #pragma lines in
source, but also have build dependencies in crypto_test, etc. The
latter was missing bssl.
The comment line should be sufficient, but being explicit is useful,
so fill in the missing one. This should help building with MINGW,
which is missing support for the usual Windows pragma.
Change-Id: Ide9328c7dd306738ebbb0792e47da96948fe12f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42105
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Update-Note: This gets rid of TRUST_TOKEN_experiment_v0. Existing callers
should be updated to call TRUST_TOKEN_experiment_v1.
Change-Id: I8ec9b808cbd35546425690d1548db671ff033e14
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41524
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
David Benjamin
Adam Langley
Steven Valdez