Re: winsock: needs access to SOCKET in application code

[Bruno Haible]

Hi Simon,

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

Yes, I agree with this. For libraries, interoperability with the system's
native data types is important.

> 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);
> }
> ...
> This approach is unclean: the code is not written in portable POSIX
> style.

Indeed. You could have completely POSIX code in gsasl if the library's
API offered each socket related API in a variant that takes a SOCKET
argument and another variablt which takes an 'fd' argument.

But if you were only the maintainer of gsasl, and the library was not
under your control, this cleaner approach is not possible, and you need
to adapt gsasl to the data types supported by the library. So, yes, I agree,
gnulib should export this _gl_fd_to_socket function (without leading
underscore, once it's supported).

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

This would be a problem, however. If you have a library which creates
SOCKET objects, then they need to be non-overlapping in order to work
with ReadFile/WriteFile, as Paolo said. How could that be guaranteed?
- I'm ok with documenting this function, if the limitation is clearly
stated, though.

> 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.
> http://plibc.svn.sourceforge.net/viewvc/plibc/trunk/plibc/src/select.c?revision=3&view=markup

This code is unreliable: it mixes the HANDLE data type with the small
integers (0 <= fd < getdtablesize()). You have no guarantee that a HANDLE
could not occasionally be in this small integer range. It may work today
and break tomorrow.

> Is there any reason why gnulib shouldn't use this approach instead?

Is it unusable because it is unreliable.

Bruno