Re: Winsock wrappers

[Paolo Bonzini]

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

Yes.

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

I think it would be very brittle, so count this as a no.

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

Agreed, but note that I meant (1) as "set the default transport
implementations to NULL under Windows".  1' just means "#undef send and
recv before setting the default transport implementation", and do not
include the send and recv modules of gnulib.

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

No, I don't think it's worthwhile.  In fact send/recv are not necessary
in the case of gnulib-provided (or in general POSIX-compliant) socket,
as programs can use read/write too in that case.

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.

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

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.

Paolo