Re: [Qemu-devel] QEMU 2.4 for Windows - current status

[Stefan Weil <sw@weilnetz.de>]

Am 05.08.2015 um 14:49 schrieb Paolo Bonzini:
> On 05/08/2015 13:03, Stefan Weil wrote:
[...]
>> slirp: Fix non blocking connect for w32
>> http://repo.or.cz/w/qemu/ar7.git/commit/b3f21d56ad3f36562d396685de8ff4981af6b805
> 
> The second looks good, but you do not need the #ifdef at all in theory.
> If you do, other breakage is looming.
> 
> Paolo

The new code was this:

          if ((tcp_fconnect(so) == -1) &&
#if defined(_WIN32)
              socket_error() != WSAEWOULDBLOCK
#else
              (errno != EINPROGRESS) && (errno != EWOULDBLOCK)
#endif
          ) {

Without the preprocessor conditionals, Linux users would get
an undefined WSAEWOULDBLOCK.

And QEMU defines a macro EWOULDBLOCK which differs from
the MinGW-w64 definition, at least in my Debian Jessie
cross environment (10035 != 140):

include/sysemu/os-win32.h:
 # define EWOULDBLOCK  WSAEWOULDBLOCK

/usr/share/mingw-w64/include/pthread.h:
 #define EWOULDBLOCK	140
/usr/share/mingw-w64/include/psdk_inc/_wsa_errnos.h:
 #define WSAEWOULDBLOCK		(WSABASEERR + 35  )

That's only a problem if we get pthread.h when compiling
for Windows. Can we be sure that this won't happen?
It looks like Windows + MinGW(-w64) is a moving target
which is not so easy to handle.

Maybe it would be better to change tcp_fconnect() to
return an ANSI error code (with a conversion from
Windows error codes in that function).

Or we introduce a wrapper for connect(), qemu_connect().

Stefan