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)

Bryan Chua | 25 Oct 20:16 2013

Conflicting definition of THREAD_INFORMATION_CLASS?

I am trying to build cygwin DLL and I keep running into a conflicting definition of THREAD_INFORMATION_CLASS:

From /usr/include/w32api/winbase.h

From src/winsup/cygwin/ntdll.h
  ThreadBasicInformation = 0,
  ThreadTimes = 1,
  ThreadImpersonationToken = 5

Which one is correct, or have I installed too many/too few packages?


-- bryan

Christopher Faylor | 21 Oct 17:10 2013

[tromey: starting git migration]

----- Forwarded message from Tom Tromey -----

From: Tom Tromey
To: Binutils Development <binutils>
CC: GDB Development <gdb>
Subject: starting git migration
Date: Mon, 21 Oct 2013 07:23:56 -0600

I'm starting the git migration now.

I've disabled commit access to binutils and gdb in CVS.
Please don't change that.

I expect the outage to last all day.


----- End forwarded message -----

This means that we will be migrating cygwin to git too RSN.



Reini Urban | 8 Oct 18:31 2013


Corinna hinted that pthread_barrier is a bit hard to implement.

I found 2 nice non-GPL implementations, but I'm not sure about the license.
There's one in libuv (which I need it for), which is
provided by Sony and Google (for Android), which seems to be MIT licensed.

And there's
without any license, looks it's some berkeley course material.

Doesn't look too hard to implement.
Should I ask the berkeley guy Brian Van Straalen
or is the libuv version good enough for us?

The GPL pthreads-win32 version looks awful in comparison.

Reini Urban

James Gregurich | 1 Oct 17:49 2013

followup on native symlink support


I've been using a recent version of cygwin with CYGWIN=winsymlinks:native setting for daily work for some
weeks. I haven't experienced any problems with the feature. Its always worked as expected. I think you
made a good choice to depart from my original design recommendation on converting relative paths that
exceed PATH_MAX to "\??\" tagged absolute paths. We have since run into some use cases where that caused
undesirable behavior. It caused symlinks that were specific to particular users on particular systems
to get committed to our repository.

I wanted to write in to thank Corrina and the other cygwin maintainers involved for finally getting tired of
hearing me whine and implementing the feature.  :)

I still need to implement a utility to update existing cygwin symlinks to native symlinks, but that isn't a
hard task…its drudgery…but not hard. 


Eric Blake | 25 Sep 23:45 2013

debugging rlimit

How am I supposed to debug code related to rlimit, when it appears that
gdb/strace resets it to default values?

$ cat foo.c
#include <stdio.h>
#include <unistd.h>
#include <sys/resource.h>
int main(void) {
  struct rlimit r;
  if (!getrlimit(RLIMIT_NOFILE, &r))
    printf("%ld %ld\n", r.rlim_cur, r.rlim_max);
  return 0;
$ ./foo
256 3200
$ (ulimit -n 1000; ./foo)
1000 3200
$ (ulimit -n 1000; strace -o /dev/null ./foo)
256 3200

Since rlimit is intertwined with getdtablesize(), I'd like to be able to
debug a process that starts with a different limit than normal.


Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Christopher Faylor | 30 Jul 21:12 2013

Cygwin changes needed for MSYS

I'm starting a new thread.  I'd like to keep the discussion confined to
what hooks we need to add to the DLL and other programming considerations.

I don't want to discuss what binaries get built for MSYS, where they
will go, or what the directory layout will look like.  I just want to
try to add enough functionality to the Cygwin DLL so that a secondary
MSYS dll can provide the functionality that MSYS users expect.

I set up a "callout" branch in the Cygwin CVS repository which will
contain the changes that I'm proposing for this project.  As I mentioned,
the intent is that an MSYS user will set the CYGWIN environment variable


Then the MSYS.dll will, as part of its dll entry function, call

cygwin_internal (CW_CALLOUT, msys_callin);

The cygwin_hook_function *could* look like:

#include <cygwin/callout.h>
extern "C" cw_callout_return_t
msys_callin (cw_callout_t code, ...)
   va_arg arg;
    cw_callout_t ret;
   switch (code)
     case CO_UNAME:
(Continue reading)

Corinna Vinschen | 11 Jul 14:59 2013

Ripping out /dev/mem support

Hi guys,

what do you think about ripping out support for /dev/mem?  It's an
entire fhandler which just doesn't make sense anymore due to lack of
support in the OS.  The only remaining supported OS, which allows to
access \Device\PhysicalMemory from user space is Windows XP 32 bit.  Not
even XP64 or 2003 allowed it anymore, not to mention Vista and later.
Keeping it up for a single, dying OS and for questionable purposes
doesn't make a lot of sense, IMHO.

This would only make sense if all systems support it, which requires to
write a device driver kind of like ioperm.  Worse, it would have to be
signed for 64 bit systems.



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

Alexey Pavlov | 4 Jul 18:52 2013

MSYS mode

As I see for now we need to handle two places in Cygwin DLL for
injecting MSYS code:
 - passing environment variables to processes
 - passing cmd arguments to processes.

From old discussion uname and fstab changes I think need to be applied
directly to Cygwin DLL.