> However, is it possible for me to ever use the send/recv replacements in > gnulib? GnuTLS doesn't open the socket, the application does, so I'm > wondering whether the FD_TO_SOCKET/SOCKET_TO_FD approach works on > something that wasn't opened by the gnulib socket function? The > application normally calls 'socket' directly, and that fd would then be > passed on to the gnulib send/recv replacement.
It depends on what you want the Windows users of GnuTLS to do. Do you want them to use something like gnulib's winsock.c, which is more POSIX-style but backwards-incompatible, or do you want them to use Winsock handles, which would be backwards-compatible but require special portability workarounds in user code? You have to make a choice, and this in turn determines whether you want to use the gnulib send/recv replacements. I see three possibilities: 1) Force users interested in Windows portability to provide their own send/recv implementation, and make the standard one only work under POSIX systems. That would be backwards-incompatible, but very easy to do. 2) Copy the winsock.c code into a file that is included in gnutls and defines gnutls_socket, gnutls_recv, gnutls_send, etc.; basically, this means provide an alternative socket implementation for Windows. For Unix, instead, you could simply "#define gnutls_socket socket" and similarly for all other functions. Then you would force users interested in Windows portability to use those functions (or gnulib, alternatively). That means some duplication, but winsock.c is not going to change very often. winsock-select.c is going to change a little more often, though, at least until a satisfactory solution for pipes is found. 3) Same as (2), but also add a flag to a GnuTLS initialization function, that says what kind of sockets they are using, and in turn what should be used to read write (socket -> Winsock's recv/send after #undef'ing the definitions in gnulib's sys/socket.h; gnutls_socket -> libc read/write). The flag would be used to initialize the send/recv function pointers to either Winsock's or gnulib's functions. The flag would be a no-op under POSIX systems. The default would be to use Winsock in order to provide backwards compatibility. Paolo