>> 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.
Instead you could have gnutls_pull_read and gnutls_push_write, not using gnulib's replacement send/recv. These could be useful on POSIX systems too (though not that much). >> 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? Yes, if the socket is created using gnulib's socket (which uses WSASocket to disable overlapped mode). > Does it respect (non-)blocking settings? Yes. Paolo
