Re: winsock: needs access to SOCKET in application code

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

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

Great.  I haven't been confident on that.

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

Ok.  Until my gnutls-hat decides to do anything, I need to work around
the problem using my gsasl-hat.

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

Come to think of it, I probably won't need this function -- gsasl only
needs to convert from fd to socket, right?  I defined it for symmetry,
but maybe it is simpler to wait until it is actually needed, so we can
learn why it is needed.

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

Is this a necessary consequence of the general approach, or a wart in
the implementation?

It seems that the general approach would lead to more portable code in
applications, so it seems preferable to me (if it can be made to work
reliably, of course).

If there is a way to reliably check whether something is a HANDLE or not
(or a low-level fd or not), the code could be re-written to cleanly
treat them as separate objects, and thus be more reliable.

/Simon