Re: windows sockets vs. file descriptors bugs in Guile

[Neil Jerram]

Scott McPeak <address@hidden> writes:

> Hi,
>
> Guile-1.8.7 appears to have socket support and Windows support, but
> they don't seem to work together, despite the existence of things like
> win32-socket.c.

I hit this too about two years ago, but never checked in my patches.
Sorry!

>  (I'm building Guile for Windows using the mingw cross
> compiler on linux.

I was building on Windows with MSVC at the time - which I believe is
quite similar to mingw cross compiling.

>  Maybe it's different with Cygwin?)

Yes, Cygwin has a thicker emulation layer underneath what Guile thinks
is the C library API.

> Specifically, Guile assumes the POSIX rule that a socket is just a
> file descriptor, but on Windows that does not work; socket functions
> only accept sockets, and file functions only accept file descriptors.
> Several Guile functions are affected; I don't think this is an
> exhaustive list, but it's what I ran into while trying to get a simple
> client and server working (see testcase below):
>
> * fport_fill_input: Passes a socket to 'read'.
>
> * write_all: Passes a socket to 'write'.
>
> * fport_close: Passes a socket to 'close'.  The EBADF error message is
> then silently discarded (...), but the bug still manifests, e.g., as a
> server that never closes its connections.

I've attached my patch for these.  It's a bit simpler than yours, and
also avoids needing copyright assignment from you.  Can you take a look,
see if you notice any disadvantages compared with your version, and if
possible try it out?

> * scm_std_select: Passes a pipe file descriptor to 'select'.

I have no record of hitting this one; I suspect my code at the time just
didn't use `sleep'.  I'm wondering if we still need scm_std_select in
Guile now anyway.  I'll write again about that.

Regards,
        Neil

0001-Use-socket-specific-operations-for-socket-ports-on-W.patch
Description: Text Data