Re: Windows fixes for sockpfaf

[Eric Blake]

Simon Josefsson <jas <at> extundo.com> writes:

> 
> There is a potential problem here, if sockpfaf is ever used without
> the sys_socket, but there is no such module today.  Maybe the
> sockpfaf.m4 file should be moved into the sys_socket module?

As long as the dependency is satisfied, with gl_HEADER_SYS_SOCKET being pulled 
in if you use sockpfaf.m4, you should be ok.

> 
> Anyway, please install.

Both patches installed, as proposed.

> 
> However, I'm not sure this is the Right Thing.  Why doesn't it work to
> include winsock2.h under cygwin?  I.e., what's in your config.log when
> the above happen?

On cygwin, you have a choice for socket implementations.  Either you use POSIX 
sockets, in which case you should never include winsock2.h because POSIX 
doesn't specify it.  Or you use winsock (which makes your application 
unportable), and you should never use sys/socket.h since Windows doesn't 
provide it.  The cygwin headers are hard-coded to reject inclusion of both 
methods, because they are vastly incompatible.  However, the cygwin community 
tends to frown on including winsock, because then your application can only be 
used in cygwin, as opposed to porting to arbitrary POSIX-like platforms.

For example:
$ cat foo.c
#include <sys/socket.h>
#include <winsock2.h>
$ gcc -c foo.c 2>&1 | head -n5
In file included from foo.c:2:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
warning: #warning "fd_set and associated macros have been defined in 
sys/types.      This may cause runtime problems with W32 sockets"
In file included from foo.c:2:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:109: 
error: redefinition of `struct timeval'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:128: 
error: redefinition of `struct linger'

> 
> Maybe there should be a USE_NATIVE_WIN32 define, which could be a
> configure-time parameter, i.e. --enable-native-win32, that toggles
> whether it should try to include winsock2.h etc or not.

Maybe, but since the cygwin community tends to frown on raw usage of winsock as 
being nonportable, it probably won't be used.  It's much easier if on cygwin, 
you pretend that winsock2.h doesn't even exist, and stick with the POSIX way of 
doing sockets.

> 
> I'm worried that the logic you are proposing will break if MinGW will
> get a sys/socket.h at some time.

Valid point, although as long as we filter all .m4 tests of sys/socket through 
gl_HEADER_SYS_SOCKET, we will only have one point to update if our current 
approach breaks.  I don't follow mingw closely enough to know if this is ever 
likely to happen, but I would argue that we don't need to worry about it unless 
it does happen.

-- 
Eric Blake