Bazel client (Windows/MSVC) crashes in server mode

[laszlocsomor]

The MSVC version (MSYS-less) bazel crashes if you run it in non-batch mode and the server isn't running.

The culprit is pretty complex and took days to debug. It consists of the following parts:

1. I narrowed down the problem to the Bazel client trying to connect to the non-running server, failing to do so, and trying to print an error. The printing code was segfaulting.

   The printing logic attempted to translate the WSAGetLastError() result to a string. This was calling gpr_format_message which crashed while calling gpr_tchar_to_char. We built non-unicode, so gpr_tchar_to_char is implemented here as just gpr_strdup, which itself is implemented here.

   On the surface, everything looks fine: gpr_strdup returns char*, gpr_tchar_to_char returns that, and gpr_format_message stores that also in a char*, however the two pointers -- dst on the return site, message on the call site -- were consistently different.

   Turns out gpr_strdup was not declared before using it, and thanks to the ancient C feature of implicit function declaration (which can be turned into an error with /WE4013), the compiler implicitly declared it with int return type, which is apparently 4 bytes long on MSVC, while char* is of course 8 bytes long. So the upper 32 bits of message were corrupt.

   So due to a missing header inclusion, we ended up implicitly declaring a function with the wrong yet compatible signature, causing a corruption of the return value which is a pointer, causing a segfault down the line.

2. We had no chance of catching it because the BUILD file of gRPC contains -Wnoimplicit-function-declaration line. Once @lberki patched this in d699a28, but we overwrote that in the next commit 8b3b918 and never noticed. All was working fine because gcc's int is 8 bytes long.

3. And even if we did notice, the MSVC wrapper script ignores that warning.

[lberki]

Woahdude. That was one hell of a bug. Nice debugging! :)