Re: Winsock wrappers

[Simon Josefsson]

Bruno Haible <address@hidden> 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 needed.
>
> That's because Paolo and I are not yet completely done with the modularization
> of <sys/socket.h>: close() and ioctl() still to be done. I intended to
> remove this unconditional AC_LIBOBJ(winsock) when the job was done.

Ah, sorry.  If you want to revert the patch meanwhile, please do, I can
use a local override in GnuTLS.

I didn't explain the entire problem.  GnuTLS doesn't build without the
patch I applied.  I use two gnulib-directories, and to avoid linking two
copies of winsock.o (which would cause duplicate symbol definitions for
static libraries) I use --avoid sys_socket in one of these directories.
Alas, some of the modules in that directory (getaddrinfo, inet_?to?,
socklen) contains AC_REQUIRE([gl_HEADER_SYS_SOCKET]).  So
AC_LIBOBJ([winsock]) is invoked in the directory without winsock.c.
This causes a hard failure when running automake: it complains about
missing winsock.c.  Is there a better way to solve this problem?

>> GnuTLS only calls recv+send from the POSIX
>> socket functions (the rest are called by the application), and it
>> handles Windows error codes internally.  Thus, I don't want send/recv to
>> be replaced by gnulib, but I want a sys/socket.h header file.
>
> Still, you will have to #undef recv and #undef send, to undo the link error
> arrangement done by gnulib (because the case of wanting module 'sys_socket'
> but not 'recv' or 'send' is much more likely to be a mistake than an
> intended configuration).

Ah, ok.  I'll make that change.

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 normally calls 'socket' directly, and that fd would then be
passed on to the gnulib send/recv replacement.

If it is not possible for some users to ever use the gnulib replacement
here, I think this should be noticed in the gnulib manual.

/Simon