On 16 March 2011 21:01, Juan Quintela <quint...@redhat.com> wrote:
> +static int tcp_server_bind(int fd, struct addrinfo *rp)
> +{
> + int val = 1;
> + int ret;
> +
> + /* allow fast reuse */
> + setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (const char *)&val,
> + sizeof(val));
> +
> + ret = bind(fd, rp->ai_addr, rp->ai_addrlen);
> +
> + if (ret == -1) {
> + ret = -socket_error();
> + }
> + return ret;
> +
> +}
I know this is just moved code, but does this do the right thing
on Windows? Windows semantics for SO_REUSEADDR are completely
different from the Unix ones:
http://blogs.msdn.com/b/wndp/archive/2005/08/03/anthony-jones.aspx
http://msdn.microsoft.com/en-us/library/ms740618%28VS.85%29.aspx
Roughly, Unix default behaviour is like Windows SO_EXCLUSIVEADDRUSE;
Unix SO_REUSEADDR is like Windows default behaviour; and Windows
SO_REUSEADDR behaviour is really weird and you don't want it.
(I think Cygwin has a workaround for this to give unix semantics,
but Windows qemu builds as a mingw app, so we get the MS semantics,
right?)
> +static int tcp_start_common(const char *str, int *fd, bool server)
> +{
[...]
> + s = getaddrinfo(name, service, &hints, &result);
> + if (s != 0) {
> + fprintf(stderr, "qemu: getaddrinfo: %s\n", gai_strerror(s));
> + return -EINVAL;
> + }
It seems a bit odd to have a low level utility routine printing
diagnostics to stderr rather than just returning the error
details to its caller somehow. Ditto the other fprintf later.
-- PMM
