Re: [PATCH] implement full-blown select(2) for winsock

[Simon Josefsson]

Paolo Bonzini <address@hidden> writes:

>>> The difference is that without these fixes, winsock is simply just too
>>> crippled for the casual Unix programmer.  Providing sys/socket.h and
>>> sys/select.h without anything like these wrappers was just giving a
>>> false sense of portability.
>> 
>> I think that is consistent with how gnulib works elsewhere: the header
>> modules just provides the header file.  They do not provide all the
>> functions declared by that header.  That is the responsibility of other
>> modules.
>
> The problem is that if you do not care about Winsock, you get close to
> zero extra portability by using the sys_socket module.  sys/socket.h is
> there for every sane platform that has sockets.
>
> But in the case of Winsock, you could include the old sys/socket.h and
> still there was basically no function in the header file that really
> worked the way you expect it to work.  Even if you restricted yourself
> to that subset you know very well -- only recv or send, don't expect
> socket descriptors to be small numbers, don't check error codes --
> there's the issue of special-casing closing sockets vs. other file
> descriptors etc.  That's what I meant by "giving a false sense of
> portability".  I'm not saying winsock.c is perfect, for example it does
> not take care of WSAStartup/WSACleanup (and there's your sockets module
> for that) but it is in my humble opinion more than decent.
>
> Bruno helped moving part of my Winsock portability stuff to the perror
> module, which was indeed a good thing and conforms with the concerns you
> expressed above.  But I think that what is left does belong in
> sys_socket, because the purpose of winsock.c is not to provide missing
> functions or to correct some detail of their operation: winsock.c is
> needed to make sys/socket.h functions work *the way anyone including
> sys/socket.h would expect them to work*.
>
> (The exact same reasoning applies for sys/select.h, which exports
> basically a single function -- making two modules for the function and
> for the header would be overkill IMHO).

I understand your point, but I don't see how the situation you describe
is different from any other replacement function in gnulib: For example
the stdio module only makes sure there is a stdio.h file to include.  It
does not pull in the fopen module, even though that the fopen module
makes the fopen function work *the way anyone including stdio.h would
expect them work*.  The gnulib way to get a fopen that works is to pull
in the 'fopen' module.

What I suggest is to place winsock_select in a separate module 'select',
and to modify sys_select (or sys_socket?) to declare select function
properly when the 'select' module is requested.  Then everyone that
wants a working select under windows can import the 'select' module.

I hope my thoughts are clearer now.  I think your code is great, and I
will use it in my projects, but my concern is maintaining the separation
between header-gnulib-modules and function-gnulib-modules.

/Simon