Re: First fix for b19 available :-)

[Christopher Hylands <cxh at EECS dot Berkeley dot EDU>]

On Sat, 28 Feb 1998 19:00:50 +0300, Sergey wrote:

> fdopen.diff
>  - fixed fdopen() call problem when fd is a pipe or socket.

I've poked around, but I can't seem to find fdopen.diff
Did these changes make it into b19.1?

While I'm at it, here's a description of the problem:

I'm porting software that uses sockets to communicate between two
processes.  Currently, the stumbling block is that under Cygwin32,
fdopen() fails with EBADF. 

Microsoft winsock info at
http://www.microsoft.com/products/developer/winsock/default.htm

says:
 In UNIX, all handles, including socket handles, are small, non-
 negative integers, and some applications make assumptions that this
 will be true.  Windows Sockets handles have no restrictions, other
 than that the value INVALID_SOCKET is not a valid socket.  Socket
 handles may take any value in the range 0 to INVALID_SOCKET-1.

As a test case, I'm using the smtp_vrfy example from:

http://www.ibrado.com/sock-faq/examples.tar.gz

This code fails with a similar error message under b19.1

I was able to get this code to compile under MSVC++ (eecch :-)
Under MSVC++ the problem was fixed by calling setsockopt() and
 _open_osfhandle():

--start--
    WORD wVersionRequested;
    WSADATA wsaData;
    int sockopt = SO_SYNCHRONOUS_NONALERT;
    wVersionRequested = MAKEWORD( 2, 0 );
[...] 
    if (WSAStartup( wVersionRequested, &wsaData )!= 0) {    
        fprintf(stderr,
                "WSAStartup: WSAGetLastError: %d\n", WSAGetLastError()); 
    }
    fprintf(stderr, "About to setsockopt() for windows\n");
    if (setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE, (char *)&sockopt,sizeof(sockopt)) < 0) {
        perror("setsockopt:");
    }
[...]
    if ( (sockread = _open_osfhandle(sock,_O_TEXT)) == -1) {
        perror("_open_osfhandle: read:");
    }
--end--

It seems like _open_osfhandle is not defined for b19.1?

Ideally, cygwin fdopen() should 'just work' like the regular Unix
fdopen(), and I should not be fooling with _open_osfhandle.  I'm
hoping that the fdopen() patch above fixes this.

-Christopher

Christopher Hylands, Ptolemy Project Manager  University of California
cxh@eecs.berkeley.edu 			      US Mail: 558 Cory Hall #1770
ph: (510)643-9841 fax:(510)642-2739	      Berkeley, CA 94720-1770
home: (510)526-4010 (if busy -4068)	      (Office: 493 Cory)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".