From:	newsham AT aloha DOT net (Tim Newsham)
Subject:	cygwin bugs
3 Jul 1997 13:37:57 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199707031838.IAA17676.cygnus.gnu-win32@haleakala.aloha.net>
Mime-Version:	1.0
Original-To:	gnu-win32 AT cygnus DOT com
X-Mailer:	ELM [version 2.4 PL24 PGP3 *ALPHA*]
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

Hi,

   Here are a number of bugs I have come cross:

- Signals cannot interrupt certain operations.

  Signals are not able to interrupt certain operations like
  a blocked read on a socket.  This causes some processes to
  be unkillable (amoung other things).  Killing the process from 
  the task manager stops the process but the cygwin state is not
  cleaned up until the last cygwin process exits.

- read() behaves differently  than in unix.

  When doing a large read() on a socket, cygwin will block until 
  the read completes.  Unix will block until there is data and
  then return whatever data is available (ie. the amount returned
  by FIONREAD).  While I believe cygwin's behavior is allowed by
  the definition of read(), it is unexpected behavior to unix
  programmers.

- select() behaves different than unix.

  When doing a nonblocking connect(), unix will allow the
  socket to select for writing when the fate of the connection
  is known (either success or failure).  Winsock on the other
  hand will allow the socket to select for writing when the connection 
  succeeds and select for exceptions when the connection fails.
  Cygwin's select() has the same behaviore as winsock's select.
  The solution would be to fold the exception bits into the write
  bits, but only when a socket is connecting.  When a socket has
  already connected then selecting for exceptions means that
  urgent data may be read, and the exception bits shouldn't
  be folded into the write bits.

- nonblocking sockets dont connect() when you tell them to.

  When establishing a connection on a non blocking socket,
  the connection is not established until the select()
  operation.  From the programmers point of view the process
  appears normal, but if you observe the packets on the wire, they
  are not sent until the select() after the initial connect().
  This is a bug in winsock and may not be worth working
  around.

- Getpeername() sometimes fails when it shouldnt.

  When establishing a connection on a non blocking socket,
  getpeername may fail immediately after a connection
  has been made.  If the getpeername() function is called
  immediately after the socket has connected (and selected
  for writing), getpeername will sometimes fail with an
  error indicating that the socket is not connected.
  If a sleep is injected before getpeername is called, getpeername
  This is a bug in the winsock getpeername function.  Perhaps
  there is an alternate way of getting the peer that is not
  flawed (getsockopt?) or some operation that can be performed
  before getpeername that will insure that getpeername operates
  correctly.

I am also trying to build a copy of cygwin from the sources.
I noticed in many places the "#include_next" directives
were failing when xgcc was being used to build programs.
There were also other errors that I ran across.  Has anyone
put together a list of instructions to build cygwin and
work around these errors?

                                  Tim N.

-
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".

- Raw text -