Paolo Bonzini <[EMAIL PROTECTED]> writes: >>> 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).
Ah, now I understand. >>> 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). Interesting. However, it is rather simple for applications to write these wrappers themselves, so I think it is better to document how to do that. Then the GnuTLS ABI doesn't depend on how gnulib have implemented sockets under Windows. /Simon
