> Will such applications break if GnuTLS would use winsock wrappers > send/recv from gnulib instead of the system's? I suspect it will, but > confirming that would be useful.
Yes. > Is there any way for gnulib to detect that a fd was created by gnulib's > winsock wrappers or the native systems? I think it would be very brittle, so count this as a no. >> 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. > > Maybe we could do the inverse: > > 1') Force users interested in gnulib/POSIX portability on Windows to > provide their own send/recv implementations, and make the standard one > only work under Windows. Agreed, but note that I meant (1) as "set the default transport implementations to NULL under Windows". 1' just means "#undef send and recv before setting the default transport implementation", and do not include the send and recv modules of gnulib. > Possibly libgnutls could define send/recv replacement functions that use > the gnulib winsock wrapper send/recv function instead of the system's, > for those applications that use gnulib winsock wrappers. No, I don't think it's worthwhile. In fact send/recv are not necessary in the case of gnulib-provided (or in general POSIX-compliant) socket, as programs can use read/write too in that case. Maybe gnutls could provide adaptors from read/write to the signature needed for gnulib's transport functions? That would be good enough to avoid duplication in client applications. >> 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. > > Isn't this the same as 1') but instead of a flag, the application needs > to set the send/recv wrapper to the functions provided by gnutls? More or less. Actually, the flag could be just "use send/recv or read/write?" because of what I said above, and that means that it could be done without including lib/winsock.c or other similarly unwanted baggage into gnutls. Paolo
