James Johnston | 25 Dec 00:01 2013

Patch to optionally disable overlapped pipes


As I have recently mentioned on the main Cygwin mailing list, Cygwin by
default creates FILE_FLAG_OVERLAPPED named pipes for the standard file
handles (stdin/stdout/stderr).  These overlapped pipes require all programs
using ReadFile/WriteFile to use overlapped I/O when using the pipes.  Since
standard runtimes in Win32 programs don't normally use overlapped I/O on the
standard file handles, most Win32 programs will exhibit undefined behavior
when called by Cygwin.  In my case, it has resulted in a problem with
calling .NET Framework 4.0 programs from Cygwin (which, coincidentally,
NETFX 4.0 also probably has a bug resulting in undefined behavior that
definitely clashes with overlapped pipes).

The attached patch creates a new "pipe_nooverlap" flag in the CYGWIN
environment variable (similar to the existing pipe_byte flag).  By default,
the flag would not be set and Cygwin will continue to make overlapped pipes
by default, because I did not know if this will result in any breakages
elsewhere in some Cygwin packages.

If the new "pipe_nooverlap" flag is set, then Cygwin won't make overlapped
pipes by default (i.e. pipes made by the pipe or pipe2 functions).  For me,
this got NETFX 4.0 programs working again.  I've been using it all day today
with no ill effects noted.  It seems safe to use.  But I made it a flag
because I am not 100% certain that some package won't break, and it isn't
needed if you are only running Cygwin programs (which presumably use
Cygwin1.dll which presumably is using overlapped I/O everywhere).

If the maintainers feel that a CYGWIN flag isn't necessary and it is safe to
always remove FILE_FLAG_OVERLAPPED, then I can submit a patch that doesn't
have the "pipe_nooverlap" flag - i.e. just assumes the flag is always set.
(Continue reading)

Ray Donnelly | 22 Dec 02:03 2013

[PATCH] Reattach trailing dirsep on existing directories too.

I hope this is OK and I've done it in the best place. Please advise if
it needs any changes.
Ray Donnelly | 22 Dec 01:40 2013

[PATCH] Fix potentially uninitialized variable p

Ray Donnelly | 22 Dec 01:39 2013

[PATCH] Fix some debug string format specifiers.

I hope patches generated with git are OK?

Best regards,

Jon TURNEY | 13 Nov 15:37 2013

[PATCH] Prototype initstate() etc. if _XOPEN_SOURCE is defined appropriately

Not sure if this is wanted, but mesa likes to compile with '-std=c99
D_XOPEN_SOURCE=500', which leads to exciting crashes on x86_64 because
initstate() is not prototyped.

2013-11-13  Jon TURNEY  <jon.turney <at> dronecode.org.uk>

	* include/cygwin/stdlib.h(initstate, random, setstate, srandom) :
	Prototype if not __STRICT_ANSI__ or _XOPEN_SOURCE is defined appropriately.
Index: cygwin/include/cygwin/stdlib.h
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/stdlib.h,v
retrieving revision 1.13
diff -u -u -p -r1.13 stdlib.h
--- cygwin/include/cygwin/stdlib.h	21 May 2013 19:04:49 -0000	1.13
+++ cygwin/include/cygwin/stdlib.h	13 Nov 2013 14:28:35 -0000
 <at>  <at>  -31,10 +31,14  <at>  <at>  void	setprogname (const char *);
 char *realpath (const char *, char *);
 char *canonicalize_file_name (const char *);
 int unsetenv (const char *);
+#endif /*__STRICT_ANSI__*/
+#if !defined(__STRICT_ANSI__) || (_XOPEN_SOURCE >= 500) || (defined(_XOPEN_SOURCE) && defined(_XOPEN_SOURCE_EXTENDED))
 char *initstate (unsigned seed, char *state, size_t size);
 long random (void);
 char *setstate (const char *state);
 void srandom (unsigned);
+#ifndef __STRICT_ANSI__
(Continue reading)

Eric Blake | 26 Sep 01:26 2013

fix off-by-one in dup2

Solves the segfault here: http://cygwin.com/ml/cygwin/2013-09/msg00397.html
but does not address the fact that we are still screwy with regards to

Ultimately, based on my understanding of POSIX and glibc, my goal is to
have a number of changes (this patch only scratches the surface; there's
more to go):

dtable.h tracks soft and hard limits, inherited over fork and preserved
across exec

hard limit starts at OPEN_MAX_MAX and can only be reduced
soft limit starts at hard limit, and can be reduced to _POSIX_OPEN_MAX (8)
dtable.size starts at MAX(32, fork/exec size)

getdtablesize() and sysconf(_SC_OPEN_MAX) always returns the soft limit,
as in glibc and permitted by POSIX (_SC_OPEN_MAX is the only sysconf
variable that can be runtime dynamic)

dtable.size is decoupled from soft limit, and is guaranteed to be <=
hard limit.  It can grow up to current soft limit; but soft limit can
later be reduced lower than dtable.size (glibc does this); on fork and
exec, we are careful to still allow fds beyond the current soft limit.

getrlimit(RLIMIT_NOFILE, &r) => returns soft and hard limits from dtable
rather than hard limit as a constant and soft limit as current dtable.size

setrlimit(RLIMIT_NOFILE, &r) => cannot set hard limit to unlimited; soft
limit of unlimited is translated to current hard limit; hard limit
(Continue reading)

Paul Kunysch | 25 Sep 12:41 2013

Re: Fix sem_getvalue

> That looks like a reasonable fix.  Did you trace through all of the
> callers of semaphore::_getvalue to make sure that some of them aren't
> relying on the old behavior?

I did not look for other callers.

I just wrote a very simple test for sem_getvalue() and copied different 
cygwin1.dll versions to my test-application.

Kunysch, Paul
Software Development

emsys Embedded Systems GmbH
Werner von Siemens Str. 20
98693 Ilmenau

Tel.: +49 3677 68977-16   Fax: +49 3677 68977-19
E-Mail: paul.kunysch <at> emsys.de
Internet: www.emsys.de

CEO: Dr.-Ing. Karsten Pahnke
office: Ilmenau
Register of commerce in county court Jena: HRB 304988

Attachment (smime.p7s): application/pkcs7-signature, 5389 bytes
Paul Kunysch | 18 Sep 11:53 2013

Fix sem_getvalue


In 1.7.24 and 1.7.25 sem_getvalue() returns the current value instead of 
setting the out-parameter and returning 0/-1 for success/error.

I attached a simple fix.

I don't know if this should be further improved by setting errno to 

Unfortunately I wasn't able to run and extend the unit tests.  Running 
"make check" fails with "No rule to make target `dataascii.o', needed by 
`libltp.a'".  The VPATH seems to be extended correctly.

Kind regards,


Kunysch, Paul
Software Development

emsys Embedded Systems GmbH
Werner von Siemens Str. 20
98693 Ilmenau

Tel.: +49 3677 68977-16   Fax: +49 3677 68977-19
E-Mail: paul.kunysch <at> emsys.de
Internet: www.emsys.de

(Continue reading)

Yaakov (Cygwin/X | 13 Sep 19:10 2013

[PATCH] cygcheck: xz packages

cygcheck needs fixing wrt .tar.xz packages; patch attached.

Attachment (cygcheck-xz-pkgs.patch): text/x-patch, 675 bytes
Yaakov (Cygwin/X | 24 Jun 07:17 2013

[PATCH] Export rawmemchr

Patch for Cygwin, pending approval of my newlib patch, attached.

Attachment (cygwin-rawmemchr.patch): text/x-patch, 2367 bytes
Warren Young | 10 May 20:19 2013

May I remove setup.xml and cygwin-ug.xml?

These files in winsup/doc appear to have been replaced by setup-net.xml 
and cygwin-ug-net.xml.  The Makefile doesn't use either of these as 
input to any of its outputs, and they're not referenced by any of the 
other input files.

Further, if you try to build a document from either of these, you get 
errors due to missing XML chunks.  (e.g. setup-reg.xml, referenced by 
setup.xml, doesn't exist.)

When I first discovered this, I thought for sure it meant I'd somehow 
screwed up the SGML to DocBook XML conversion, but ruled that out thus:

     $ grep -Rsl setup-reg winsup

If you do that to both the current tree and to a tree rolled back to 
before I got my commit bit, you find that only setup.{xml,sgml} contains 
that string.  It means the pre-Warren tree couldn't build documents from 
this file, either.

I'm not in any particular hurry to get rid of these files.  They only 
trouble they're causing is the same any clutter causes.  I want to make 
sure no one knows a reason either has to remain in existence before I 
nuke them.