Re: Winsock wrappers

[Simon Josefsson]

Paolo Bonzini <address@hidden> writes:

>> 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?

We want to support Windows programs, compiled using MSVS or Mingw, that
calls 'socket' and so on from the native Windows libraries, and link to
GnuTLS for the TLS protocol.  These applications can't be required to
use the Winsock wrappers in gnulib.  This implies that gnutls needs to
call the system's recv/send with the fd passed on from the application.

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.

Is there any way for gnulib to detect that a fd was created by gnulib's
winsock wrappers or the native systems?

> 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.

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.

I believe applications that use gnulib winsock wrappers be in the
minority for the next few years at least, so this seems a better
trade-off to me.

> 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.

This means worrying more about particular system's socket
implementations, and we want to avoid that.  Right now the only socket
function we call is send/recv using the application's fd.  Going beyond
that will most likely lead to even more complex problems later on.

> 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?

/Simon