Paolo Bonzini <[EMAIL PROTECTED]> 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
