>> 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). Paolo
