[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Winsock wrappers
From: |
Paolo Bonzini |
Subject: |
Re: Winsock wrappers |
Date: |
Thu, 09 Oct 2008 10:38:54 +0200 |
User-agent: |
Thunderbird 2.0.0.17 (Macintosh/20080914) |
> 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
- Winsock wrappers, Simon Josefsson, 2008/10/08
- Re: Winsock wrappers, Bruno Haible, 2008/10/08
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/09
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers,
Paolo Bonzini <=
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/09
- Re: Winsock wrappers, Simon Josefsson, 2008/10/09
- Re: Winsock wrappers, Bruno Haible, 2008/10/10
- Re: Winsock wrappers, Simon Josefsson, 2008/10/10
- Re: Winsock wrappers, Paolo Bonzini, 2008/10/10
- Re: getaddrinfo and sa_len, Bruno Haible, 2008/10/10
- Re: predefined CPP macros, Bruno Haible, 2008/10/10