[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU 2.4 for Windows - current status
From: |
Stefan Weil |
Subject: |
Re: [Qemu-devel] QEMU 2.4 for Windows - current status |
Date: |
Thu, 10 Sep 2015 22:38:36 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] QEMU 2.4 for Windows - current status,
Stefan Weil <=