Re: winsock: needs access to SOCKET in application code

[Simon Josefsson]

Bruno Haible <address@hidden> 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 somewhat prefer to see the declaration of this
> function in <sys/socket.h> and its implementation in a separate
> module.

Sounds good, although sys/socket.h is currently not generated on system
that has a sufficiently good sys/socket.h.

Maybe it is simpler to create a completely new module for this.
However, it would just be a static inline function in a *.h file...

So maybe putting this in sockets.h is less ugly than putting it yet
another tiny module.  Thoughts?

>> +int gl_sockets_from_fd (int fd);
>
> 'sockets' in plural? I think 'gl_socket_from_fd' would be better, or
> 'gl_fd_to_socket'?

I was trying to maintain the sockets.h gl_sockets* namespace...

> 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 winsock wrappers.  It needs to be a nop on other systems.

Maybe something like:

#if ?
static inline SOCKET
gl_fd_to_handle (int fd)
{
  return _get_osfhandle (fd);
}
#else
#define gl_fd_to_handle(x) (x)
#endif

> Also, it would be good to either have this function return INVALID_SOCKET
> if it's not a socket, for robustness - or name the function differently,
> to make it clear that the result can be any HANDLE, not necessarily a socket.

I renamed the function above, I think it is unlikely that the same
approach will be applicable to non-mingw systems, so let's do the
minimal amount of work to make things work under mingw.

/Simon