Re: ws2_32: Only examine lower-order bits in getsockopt/setsockopt

[Alexandre Julliard]

Juan Lang <juan.lang(a)gmail.com> writes:
> @@ -1779,6 +1779,8 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
>      TRACE("socket: %04lx, level 0x%x, name 0x%x, ptr %p, len %d\n",
>            s, level, optname, optval, *optlen);
>
> +    /* Some apps sign-extend the level, so mask off the higher-order bits */
> +    level &= 0x0000ffff;

There can be several other ways to handle this, it needs test cases to
determine which way Windows is using.

-- 
Alexandre Julliard
julliard(a)winehq.org

ws2_32: Only examine lower-order bits in getsockopt/setsockopt

[Juan Lang]

> There can be several other ways to handle this, it needs test cases to
> determine which way Windows is using.

Sorry for my lack of imagination:  could you suggest at least one
other way so I can make sure the tests are representative?

Thanks,
--Juan

ws2_32: Only examine lower-order bits in getsockopt/setsockopt

[Alexandre Julliard]

Juan Lang <juan.lang(a)gmail.com> writes:
> > There can be several other ways to handle this, it needs test cases to
> > determine which way Windows is using.
>
> Sorry for my lack of imagination:  could you suggest at least one
> other way so I can make sure the tests are representative?

It may check for just 0xffffffff as a special case, or check for high
word being 0 or 0xffff and rejecting others, etc. Some values to test
would be things like 0x1234ffff, 0x12340000, 0xffff0000, etc.

-- 
Alexandre Julliard
julliard(a)winehq.org

ws2_32: Only examine lower-order bits in getsockopt/setsockopt

[Detlef Riekenberg]

On Do, 2009-08-20 at 18:22 +0200, Alexandre Julliard wrote:
> Juan Lang <juan.lang(a)gmail.com> writes:
> > > There can be several other ways to handle this, it needs test cases to
> > > determine which way Windows is using.
> >
> > Sorry for my lack of imagination:  could you suggest at least one
> > other way so I can make sure the tests are representative?
>
> It may check for just 0xffffffff as a special case, or check for high
> word being 0 or 0xffff and rejecting others, etc. Some values to test
> would be things like 0x1234ffff, 0x12340000, 0xffff0000, etc.

Jeff did a patch in the bug, which check for SOCKET_ERROR, when
setsockopt
was called with 0xffffffff as level:
http://bugs2.winehq.org/attachment.cgi?id=20211

I'm offline tomorrow, otherwise i woud add more tests to my old patch.


-- 
 
By by ... Detlef

ws2_32: Only examine lower-order bits in getsockopt/setsockopt

[Detlef Riekenberg]

On Do, 2009-08-20 at 17:58 +0200, Alexandre Julliard wrote:
> Juan Lang <juan.lang(a)gmail.com> writes:
> > @@ -1779,6 +1779,8 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
> >      TRACE("socket: %04lx, level 0x%x, name 0x%x, ptr %p, len %d\n",
> >            s, level, optname, optval, *optlen);
> >
> > +    /* Some apps sign-extend the level, so mask off the higher-order bits */
> > +    level &= 0x0000ffff;
>
> There can be several other ways to handle this, it needs test cases to
> determine which way Windows is using.

When reading the log in the bug, the WSAAsyncGetHostByName16 is the
indicator for an 16bit app. 

Attached is my diff from last year for that code.

-- 
 
By by ... Detlef

ws2_32: Only examine lower-order bits in getsockopt/setsockopt

[Juan Lang]

Hi Detlef,
> When reading the log in the bug, the WSAAsyncGetHostByName16 is the
> indicator for an 16bit app.

Right you are.  I ignored that, but clearly I was mistaken.
> Attached is my diff from last year for that code.

The changes you made to getsockopt16 and setsockopt16 look correct.
The tests you added only trace values, whereas Jeff showed that my
patch is in fact wrong.

So:  it seems as though your changes to getsockopt16 and setsockopt16,
and Jeff's tests, should get sent in.  Do you want to send them in, or
would you prefer that I do?

Thanks,
--Juan