[ovs-dev] [PATCH] poll-loop: fix assertion in poll_create_node

[Gurucharan Shetty]

On Tue, Sep 29, 2015 at 8:49 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Wed, Sep 30, 2015 at 02:44:15AM +0000, Alin Serdean wrote:
>> The ides is the following:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms740094%28v=vs.85%29.aspx
>> and SOCKET is defined as:
>> typedef UINT_PTR        SOCKET;
>>
>> When we do the following:
>> node->pollfd.fd = fd;
>> and fd = -1, node->pollfd.fd will rollover.
>
> That pages talks, twice, about negative values of fd.  That's
> *intentionally* goddamn deceptive for talking about an unsigned type.
> Microsoft should fix their documentation.  Maybe someone with an account
> should add a comment on the page.
>
> But: maybe we're doing totally the wrong thing if a SOCKET is really a
> UINT_PTR, because that means we need a 64-bit (unsigned) type and we're
> using an int in the function prototypes.  Maybe we need to change all
> the function prototypes to use `int' on Unix and `SOCKET' on Windows
> (presumably via typedef).

Googling a bit around, it looks like many people have made the
assumption that even though on 64 bit Windows, socket can
theoretically return 64 bit number, it actually does not. The
following comment from OpenSSL (here:
https://github.com/openssl/openssl/blob/master/e_os.h#L478) is cited
as a justification :

/*
* Even though sizeof(SOCKET) is 8, it's safe to cast it to int, because
* the value constitutes an index in per-process table of limited size
* and not a real pointer.
*/






>
> On the other hand, I guess socket() can't just be returning random
> 64-bit numbers as SOCKET values, since that would totally break the
> select() function that Winsock appears to support at least somewhat.
> Maybe it always returns a small integer.  (However, if it ever returns
> zero...).