> But the internal gnulib implementation might change, right? I mean, the
> FD_TO_SOCKET macro is an implementation detail in gnulib, but if that
> ever changes, it would break binary compatibility if GnuTLS exposes the
> SOCKET vs int difference.
No, there's no other sensible way. The macro is
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon wrote:
>> Is there any way for gnulib to detect that a fd was created by gnulib's
>> winsock wrappers or the native systems?
>
> Actually these two are different types: gnulib's file descriptors are 'int&#x
Simon wrote:
> Is there any way for gnulib to detect that a fd was created by gnulib's
> winsock wrappers or the native systems?
Actually these two are different types: gnulib's file descriptors are 'int'
in the small nonnegative range, whereas a SOCKET is actually a HA
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> 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.
>>
>> I think this was what I meant above, but I'm not sure I
>> 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.
>
> I think this was what I meant above, but I'm not sure I understand you.
> What I see gnutls defining w
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> 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.
Thanks.
>>>
> 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 wrapp
dows programs, compiled using MSVS or Mingw, that
calls 'socket' and so on from the native Windows libraries, and link to
GnuTLS for the TLS protocol. These applications can't be required to
use the Winsock wrappers in gnulib. This implies that gnutls needs to
call the system's r
> However, is it possible for me to ever use the send/recv replacements in
> gnulib? GnuTLS doesn't open the socket, the application does, so I'm
> wondering whether the FD_TO_SOCKET/SOCKET_TO_FD approach works on
> something that wasn't opened by the gnulib socket function? The
> application no
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
>> I have seen Bruno's recent patch to add separate modules for each and
>> every socket function. That's a better approach IMHO.
>>
>> Further, as far as I can tell, Bruno's gnulib module descriptions will
>> pull in the winsock file when n
Hi Simon,
> I have seen Bruno's recent patch to add separate modules for each and
> every socket function. That's a better approach IMHO.
>
> Further, as far as I can tell, Bruno's gnulib module descriptions will
> pull in the winsock file when needed.
That's because Paolo and I are not yet com
With GnuTLS 2.6.0 released, I finally have time to look into the winsock
wrappers.
This patch:
> --- a/m4/sys_socket_h.m4
> +++ b/m4/sys_socket_h.m4
> @@ -64,6 +64,9 @@ AC_DEFUN([gl_HEADER_SYS_SOCKET],
> HAVE_WS2TCPIP_H=0
>fi
> fi
> +if test x$ac
I'm applying these (obvious) tweaks. The 'errno' module is needed because
of the reference to EWOULDBLOCK added recently.
2008-10-05 Bruno Haible <[EMAIL PROTECTED]>
* lib/winsock.c (strerror): Remove unused #undef.
(rpl_close): Remove unused local variable.
* modules/s
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>
>>> Tested together with patch 3/3. Ok?
>>
>> I haven't tested it, but will do now that it has been installed.
>>
>> However, just to confirm, the sys_socket module needs to remai
Simon Josefsson wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> writes:
>
>> Tested together with patch 3/3. Ok?
>
> I haven't tested it, but will do now that it has been installed.
>
> However, just to confirm, the sys_socket module needs to remain
> LGPLv2.1+, and that's what the module descriptio
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Tested together with patch 3/3. Ok?
I haven't tested it, but will do now that it has been installed.
However, just to confirm, the sys_socket module needs to remain
LGPLv2.1+, and that's what the module description says, did you intend
this for the wi
> The rpl_close wrapper in winsock.c will collide with the one in fchdir.c.
> We can work on it after you commit your patch.
I'll leave this to you...
> Also, I would like to have select() implemented right, as I need it in the
> 'msgfilter' program. But that's also for afterwards.
... as a deal
Hi Paolo,
Thanks for this big step ahead!
In set_winsock_errno, I think we also need to convert the three possible error
values below 100. See
http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00136.html
http://msdn.microsoft.com/en-us/library/ms740668(VS.85).aspx
The rpl_close wrapper
There are two changes compared to previous versions of the patch:
1) The socket wrapper calls WSASocket to return a "non-overlapped"
socket. Overlapped sockets cannot be read and written with read/write
(i.e. Win32 API functions ReadFile/WriteFile), only with
ReadFileEx/WriteFileEx -- besides rec
Bruno Haible wrote:
> Hi Paolo,
>
> Paolo Bonzini wrote:
>> except the need to
>> move parts of the sys_socket module to errno/stdio/string.
>
> I can do that for you. It's the usual gnulib macrology and substology.
>
>> 2) regarding string, strerror does not need to be replaced under mingw;
>
Hi Paolo,
Paolo Bonzini wrote:
> except the need to
> move parts of the sys_socket module to errno/stdio/string.
I can do that for you. It's the usual gnulib macrology and substology.
> 2) regarding string, strerror does not need to be replaced under mingw;
Huh? strerror is declared by mingw's
This patch fixes all the issues that Bruno found, except the need to
move parts of the sys_socket module to errno/stdio/string. I didn't do
that for these reasons:
1) regarding errno, the #defines were already there before the patch;
2) regarding string, strerror does not need to be replaced und
22 matches
Mail list logo
