David Stacey | 15 Mar 20:51 2015

backtrace(3) in Cygwin

Following on from my thread on the main list [1], I have made an initial 
attempt at implementing backtrace(3) and backtrace_symbols(3). This 
still needs a little work - at the moment, the paths in the strings will 
be DOS-style rather than POSIX. However, I wanted to submit an early 
version to make sure you were happy with my approach before I spend more 
time on it.

I've also documented (in the code) the issues surrounding 
backtrace_symbols_fd(3) on Cygwin.

This is my first real submission to the programme - be kind :-)


[1] - http://cygwin.com/ml/cygwin/2015-03/msg00198.html

Attachment (exec_info.c): text/x-csrc, 7786 bytes
Corinna Vinschen | 5 Mar 16:12 2015

Evil deed: Switching development repository to git

Hi folks,

next week, I'm planning to move the combined newlib/libgloss and cygwin
repository from CVS to git.  The basic stuff is quickly done, but hooks,
mailing list handling, and changes to the websites are to be done, so I
expect the switch to take about two days.

I'll set up a commit moratorium starting next Monday at about 10:00 UTC.

When the git repo is up and working I'll throw the lever and inform the
mailing lists.  Afterwards you can expect to access the new combined
newlib/cygwin git repository via either

  git clone git://sourceware.org/git/newlib-cygwin.git

or, if you have write permissions on the repo

  git clone sourceware.org:/git/newlib-cygwin.git

or, for the web view:




Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
(Continue reading)

Jon TURNEY | 17 Feb 19:24 2015

Fwd: A small issue with _GNU_SOURCE

Consider the following:

$ cat test.c
#include <string.h>
#include <stdlib.h>

int main()
  long long i = random();
  return ffsll(i);

ffsll() is a GNU extension and should be prototyped when _GNU_SOURCE is 

random() is in SUSv2 and requires _XOPEN_SOURCE=500

$ gcc test.c -Wall -ansi -D_XOPEN_SOURCE=700
test.c: In function ‘main’:
test.c:8:2: warning: implicit declaration of function ‘ffsll’

This is correct

$ gcc test.c -Wall -ansi -D_XOPEN_SOURCE=700 -D_GNU_SOURCE
test.c: In function ‘main’:
test.c:8:2: warning: implicit declaration of function ‘ffsll’

This looks like a problem with newlib's sys/cdefs.h.  _XOPEN_SOURCE 
causes _POSIX_C_SOURCE to be defined, which prevents _GNU_SOURCE from 
(Continue reading)

George Prekas | 12 Nov 11:35 2014

Unexpected behavior using arrow keys on the terminal

Using Cygwin 1.7.32, mintty 1.1.3 and OpenSSH_6.7p1 I am getting unexpected behavior regarding the use of
arrow keys on the terminal. You can reproduce the behavior by doing the following:

ssh linux
cd /usr/src/linux/tools/perf
cd ~
/usr/src/linux/tools/perf/perf record echo 42
/usr/src/linux/tools/perf/perf report

Pressing UP or DOWN should highlight one of the rows displayed. You can verify expected behavior by using
either PuTTY or native Linux.

Observation #1: You can fix perf's behavior by applying perf.patch (attached).

Observation #2: Using Wireshark, I've observed that when I ssh to a host and press UP or DOWN on my terminal 3
packets are transmitted from the client. PuTTY on the other hand transmits only 1 packet (larger in size).

Observation #3: I wrote the program test.c (attached). If I run it and press UP or DOWN:
* on Windows from cmd.exe it says "Read 3 bytes. First is 27."
* on Linux it says "Read 3 bytes. First is 27."
* on Linux via PuTTY it says "Read 3 bytes. First is 27."
* on Windows from mintty.exe it says "Read 1 bytes. First is 27. Read 1 bytes. First is 91. Read 1 bytes. First
is 65."

My understanding is that the unexpected behavior occurs because Cygwin sends the UP/DOWN sequence one
byte at a time. Specifically:

* winsup\cygwin\fhandler_tty.cc  <at>  fhandler_pty_master::write
    This is the function called by the write system call invoked by mintty. Here len = 3. line_edit is invoked 3 times.
(Continue reading)

Christian Franke | 16 Oct 23:34 2014

Cygwin AF_UNIX emulation

Hi Corinna,

Corinna Vinschen wrote:
> On Oct 13 07:37, Christian Franke wrote:
>>> I
>>> also added a comment to explain why we do this and a FIXME comment so we
>>> don't forget we're still looking for a more generic solution for the
>>> SO_PEERCRED exchange.
>> Definitely, at least because the current AF_LOCAL emulation has some
>> security issues.
> -v?

With the secret+cred exchange, the current implementation is IMO 
reasonably safe. The client cannot connect without access to the socket 

Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- 
and relies only on directory permissions (private: rwx------, public: 
rwx--x---) for access control. This is not effective on Cygwin. Due to 
the rw-rw-rw-, the 'secret' is world readable on Cygwin and another 
Cygwin specific patch is required :-)

After new setsockopt(sd, ., SO_PEERCRED, .), AF_UNIX sockets are 
definitely vulnerable. Any local process could "guess" the TCP port and 
connect to any emulated AF_UNIX server regardless of user account.

Two draft ideas for a new AF_UNIX emulation:

Keep the current secret+cred exchange, but handle accept() and connect() 
(Continue reading)

Ryan Johnson | 12 Jul 19:53 2014

Broken header dirent.h

Hi all,

Please CC me in replies, I'm no longer a list member.

I recently tried to use <sys/dirent.h> in a C++ program and got linker 
errors. Turns out the header is neither C++-aware (extern "C") nor 
cygwin-aware (_EXFUN).

The attached patch fixes the problem for me.


--- dirent.h.orig	2014-05-23 04:36:40.000000000 -0400
+++ dirent.h	2014-07-12 12:31:44.904628400 -0400
 <at>  <at>  -15,6 +15,10  <at>  <at> 
 #include <sys/types.h>
 #include <limits.h>

+#ifdef __cplusplus
+extern "C" {
 #define __DIRENT_VERSION	2

 #ifndef __x86_64__
 <at>  <at>  -62,32 +66,32  <at>  <at> 
 #pragma pack(pop)
(Continue reading)

Jon TURNEY | 20 Jun 15:04 2014

cygwin-doc and newlib manpages

The man page for the printf family of functions in the cygwin-doc 
package is only installed under the name sprintf, and not any of the 
names of other functions it also documents (printf, fprintf, etc.)

Looking into this, it seems that the cygwin-doc scripts are supposed to 
do this, but have been broken for some time, as the index in the .info 
file the manpages are generated from has a different header ('Document 
Index') to that expected ('Index').

First attached patch is to fix that.

Unfortunately, I needed to do a bit more fixing up of cygwin-doc for a 
working build, and it also seems that it needs some updating for last 
year's Docbook XML  modernization.

Trying to to do that, the cygwin2info Makefile rule has some problem I 
don't understand.

On the .sgml files, it dies with "Can't call method "ext" without a 
package or object reference at 
/usr/share/sgml/docbook/utils-0.6.14/helpers/docbook2texi-spec.pl line 
320, <STDIN> line 2."

Also, I think this probably needs to be (somehow) updated to use 
docbook2x-texi on the .xml files

Fix generation of aliased manpages with current info files
(Continue reading)

Lukas Haase | 10 May 04:50 2014

Cygwin socket internals and WinAPI interface


From my application I would like to create ("export") a socket in native Windows API which can then be used by
cygwin programs.

I.e., if I would write the "server" in cygwin, I would use socket(PF_LOCAL), select, read, write etc.
However, I cannot use cygwin because the application is developed in VC and C++ so I want to emulate this
functionality using only WinAPI functions.

Socket files are just plain files containing stuff like:

!<socket >54359 s 7B499653-622A1EB9-83E6B83E-A4E8D0C1

The first number is a port number as I understand, the 's' stands for socket I guess but what is the GUID number for?
What steps do I need to perform except creating a windows socket on localhost at this port and writing the
socket file?


Alexey Pavlov | 28 Nov 09:03 2013

Fix invalid use of restrict

In CVS version I get error: invalid use of restrict. Patch for it is below

From 2a2164e5ed7cf6220ae7b2f7dac3016e1bf9293e Mon Sep 17 00:00:00 2001
From: Alexpux <alexey.pawlow@...>
Date: Thu, 28 Nov 2013 12:01:15 +0400
Subject: [PATCH] Fix invalid use of 'restrict' error.

 winsup/cygwin/include/glob.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/include/glob.h b/winsup/cygwin/include/glob.h
index 4ad200f..59f0efc 100644
--- a/winsup/cygwin/include/glob.h
+++ b/winsup/cygwin/include/glob.h
 <at>  <at>  -103,7 +103,7  <at>  <at>  __BEGIN_DECLS
 # define DLLEXPORT __declspec(dllimport)

-int DLLEXPORT glob (const char __restrict *, int, int (*)(const char
*, int), glob_t *__restrict);
+int DLLEXPORT glob (const char *__restrict, int, int (*)(const char
*, int), glob_t *__restrict);
 void DLLEXPORT globfree (glob_t *);
 int DLLEXPORT glob_pattern_p (const char *, int);

-- (Apple Git-47)

(Continue reading)

Christopher Faylor | 23 Nov 19:38 2013

Splitting up cygwin packages

I'll probably regret mentioning this because it is a potential bikeshed
issue but, here goes:

I suggested to Corinna that it would be nice to break up the cygwin package
into four different packages:

- cygwin		Category: base

containing the dll

- cygwin-devel		Category: devel

containing headers and import libraries

- cygwin-server		Category: base(?)

containing cygserver and cyglsa

- cygwin-utils		Category: base

containing the content of winsup/utils

The versioning for all of the above would reflect the dll version.

There are two motivations here:

1) Allow updating non-dll packages for important bug fixes which
do not require a dll version bump (like the recent cygcheck bug).
This would be a rare occurrence but it means that there could be,
e.g., a cygwin-utils-1.7.27-2 package.  The utilities would report
(Continue reading)

Corinna Vinschen | 18 Nov 12:05 2013

IDN support in getaddrinfo/getnameinfo

Hi guys,

I'd like to have your opinion.

Yesterday I started a small fun-project.  For a while now we have
International Domain Names (IDNs) per RFC 3490.

IDN support usally works like this: There's the libidn project which
provides the "idna_to_ascii" and "idna_to_unicode" functions.  And then
there are the getaddinfo and getnameinfo functions.  Typically the
getaddinfo and getnameinfo functions don't support IDNs directly, so
IDNs are converted to and from punycode using the libidn functions.

But then there's glibc.  Since version 2.3.4, it supports an extension
to the getaddrinfo and getnameinfo functions.  Without going into too
much detail, glibc introduced AI_IDN* flags for getaddrinfo and NI_IDN*
flags for getnameinfo which cover the full functionality provided by
the libidn calls.  That means, a glibc-aware project does not have to
link against libidn, if it uses the new getaddrinfo/getnameinfo flags.

My small fun-project is adding the AI_IDN* and NI_IDN* flags to Cygwin.
The required libidn functionality exists 100% identically in
kernel32.dll since Windows Vista(1) (IdnToAscii/IdnToUnicode) including
the modifier flags, so it's just a matter of calling the UNICODE
functions GetAddrInfoW/GetNameInfoW and calling these IdnToXXX
functions, just like glibc additionally calls idna_to_ascii_lz, etc.  My
new getnameinfo already works with IDNs, the getaddrinfo isn't quite
finished yet.

However, is that really worth the effort?  A portable project won't
(Continue reading)