Paolo Bonzini <[EMAIL PROTECTED]> writes: >> 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.
Thanks. >>> 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. Ok, I see. I think I prefer 1' since it is easier for Windows users, and doesn't have any significant disadvantages. >> 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. The lesser code the better. > 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. I think this was what I meant above, but I'm not sure I understand you. What I see gnutls defining would be something like: ssize_t gnutls_gnulib_pull (gnutls_transport_ptr_t, void *, size_t); ssize_t gnutls_gnulib_push (gnutls_transport_ptr_t, const void *, size_t); These would be implemented using gnulib's replacement send/recv functions. Then applications that have opened a socket via gnulib's module are required to call: gnutls_transport_set_push_function (session, gnutls_gnulib_push); gnutls_transport_set_pull_function (session, gnutls_gnulib_pull); I'm not sure I follow your read/write reference though. This is sort of ugly, and maybe it is better for gnulib-applications to specify these callbacks themselves. Consider if gnulib's winsock.c implementation changed internally, then I would need to bump the GnuTLS ABI just because of this. I think I just talked myself out of doing this. >>> 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. Are you saying that read/write on the socket would work under Windows? Does it respect (non-)blocking settings? /Simon
