winsock: needs access to SOCKET in application code

[Simon Josefsson]

Paolo, Bruno,

I'm starting to integrate the winsock modules in my projects.

As we discussed earlier, and as far as I understand, the only approach
for a project like libgnutls -- that needs compatibility with native
Windows programs -- is to accept a SOCKET handle from the application,
and call the native send/recv.  (If you believe this assumption is the
real problem, I'll discuss other approaches, but please read on to
understand a problem in the current gnulib winsock approach.)

My next step has been to use the modules in GNU SASL and in the GnuTLS
command-line applications.  For some reason, it is simpler to start with
gsasl.  It contains a simple command line tool that read/write from the
network and stdin/stdout (using select or poll).

If I use gnulib modules in gsasl, the idea is that all portability
problems should be taken care of using the gnulib winsock code.
However, that isn't the case when the connection are TLS protected.  I
need to pass a SOCKET handle to GnuTLS, instead of the FD handle that
winsock wrappers created.  Thus, I need some functions like:

SOCKET _gl_fd_to_socket (int fd)
{
  return FD_TO_SOCKET(fd);
}

int _gl_socket_to_fd (SOCKET fh)
{
  return SOCKET_TO_FD(fh);
}

They should probably be in winsock.c, and declared in some header file.

The gsasl code then needs to use the _gl_socket_to_fd function when
passing the network socket from the application down to gnutls.

This approach is unclean: the code is not written in portable POSIX
style.

In contrast, I think gnulib could use another approach.  Winsock.c would
not use the socket2fd conversion, and instead use native sockets all the
time.  The open/socket/connect/etc wrappers would then only convert
Windows error handling to errno, it would not modify the return value
from the native Windows functions.

The only problem with this approach that I can see is that select and
poll needs to be implemented differently.  However, for select there is
one in PlibC:

http://plibc.svn.sourceforge.net/viewvc/plibc/trunk/plibc/src/select.c?revision=3&view=markup

It is not copyrighted by the FSF, but it would be relatively simple to
rewrite.

The advantage with this latter approach would be that gsasl can remain
written as portable code: I don't need to invoke any special functions
just to have it work under Windows.

Is there any reason why gnulib shouldn't use this approach instead?  It
seems to result in cleaner application code to me, which should be
gnulib's goal.

/Simon