From: cxh AT EECS DOT Berkeley DOT EDU (Christopher Hylands) Subject: Re: First fix for b19 available :-) 18 Apr 1998 22:05:43 -0700 Message-ID: <199804181836.LAA07651.cygnus.gnu-win32@carson.eecs.berkeley.edu> To: sos AT buggy DOT prospect DOT com DOT ru Cc: gnu-win32 AT cygnus DOT com 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 AT eecs DOT berkeley DOT 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 AT cygnus DOT com" with one line of text: "help".