Bruno Haible writes:
> Simon,
>
>> +/* This function is useful it you create a socket using gnulib's
>> + Winsock wrappers but needs to pass on the socket handle to some
>> + other library that only accepts sockets. */
>> +#if WINDOWS_SOCKETS
>> +static inline SOCKET
>> +gl_fd_to_handle (int
Simon,
> +/* This function is useful it you create a socket using gnulib's
> + Winsock wrappers but needs to pass on the socket handle to some
> + other library that only accepts sockets. */
> +#if WINDOWS_SOCKETS
> +static inline SOCKET
> +gl_fd_to_handle (int fd)
> +{
> + return _get_osfhan
This thread never resulted in a change, but I need one now. I re-read
the earlier discussions, and some points:
1) It is useful if the gl_fd_to_socket function is available on all
systems, to avoid ugly #if's in code that uses it.
Corollary: declaring it in sys/socket.h seems wrong because
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
>> > The return type should be SOCKET, which is either `unsigned int' or
>> > 'unsigned long' (don't know about win64).
>>
>> How would that work on non-Mingw systems? The idea should be that gsasl
>> calls the function unconditionally, in o
Hi Simon,
> > The return type should be SOCKET, which is either `unsigned int' or
> > 'unsigned long' (don't know about win64).
>
> How would that work on non-Mingw systems? The idea should be that gsasl
> calls the function unconditionally, in order to work around limitations
> of the gnulib wi
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Maybe something for the 'sockets' module, it is rather Windows specific?
>
> Hmm, I see the 'sockets' module more like the general facilities, that
> everyone who uses sockets needs.
I think you are right.
> I would therefore s
Simon Josefsson wrote:
> Maybe something for the 'sockets' module, it is rather Windows specific?
Hmm, I see the 'sockets' module more like the general facilities, that
everyone who uses sockets needs. I would therefore somewhat prefer to see
the declaration of this function in and its implementa
> 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.
Both HANDLEs and fds are indexes into a table, in the end. So you can
check if X is a HAND
> Maybe something for the 'sockets' module, it is rather Windows specific?
> How about the patch below?
You maintain the module; but yes, it's fine by me.
Paolo
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> I need to pass a SOCKET handle to GnuTLS, instead of the FD handle that
>> winsock wrappers created.
>
> You can also install your own GnuTLS transport handlers using read and
> write. It would probably be less code and less complication than
> togglin
Bruno Haible <[EMAIL PROTECTED]> 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
> I need to pass a SOCKET handle to GnuTLS, instead of the FD handle that
> winsock wrappers created.
You can also install your own GnuTLS transport handlers using read and
write. It would probably be less code and less complication than
toggling between descriptors and sockets.
>> SOCKET _gl_fd
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
Paolo, Bruno,
I'm starting to integrate the winsock modules in my projects.
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 t
14 matches
Mail list logo
