[PATCH] Cygwin: redefine some macros for Linux compatibility

[PATCH] Cygwin: redefine some macros for Linux compatibility

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Patch attached.

I wasn't sure whether the API bump was warranted for such a trivial change.  But 
the fact is that some programs compiled prior to the patch will behave 
differently if they are recompiled after the patch.  For example, emacs limits 
the number of open subprocesses to FD_SETSIZE, so this number will change when 
emacs is recompiled for Cygwin 3.4.0.  Is that a good enough reason to bump the API?

Ken

[-- Attachment #2: 0001-Cygwin-redefine-some-macros-for-Linux-compatibility.patch --]
[-- Type: text/plain, Size: 3950 bytes --]

From 6d6c1ed356e3e8f39aa9b6447982f3fccbdabfad Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Wed, 6 Jul 2022 14:43:16 -0400
Subject: [PATCH] Cygwin: redefine some macros for Linux compatibility

Define FD_SETSIZE (<sys/select.h>) to be 1024 by default, and define
NOFILE (<sys/param.h>) to be OPEN_MAX (== 3200) by default.

Remove the comment in <sys/select.h> that FD_SETSIZE should be >=
NOFILE.

Bump API minor.

Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html
---
 newlib/libc/include/sys/select.h       | 10 +++++++---
 winsup/cygwin/include/cygwin/version.h |  3 ++-
 winsup/cygwin/include/sys/param.h      |  4 +++-
 winsup/cygwin/release/3.4.0            |  4 ++++
 winsup/doc/new-features.xml            |  5 +++++
 5 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/newlib/libc/include/sys/select.h b/newlib/libc/include/sys/select.h
index a5cd6c3fe..93d0b79bf 100644
--- a/newlib/libc/include/sys/select.h
+++ b/newlib/libc/include/sys/select.h
@@ -25,10 +25,14 @@ typedef	__sigset_t	sigset_t;
  * Select uses bit masks of file descriptors in longs.
  * These macros manipulate such bit fields (the filesystem macros use chars).
  * FD_SETSIZE may be defined by the user, but the default here
- * should be >= NOFILE (param.h).
+ * should be enough for most uses.
  */
-#ifndef	FD_SETSIZE
-#define	FD_SETSIZE	64
+#ifndef FD_SETSIZE
+# ifdef __CYGWIN__
+#  define FD_SETSIZE	1024
+# else
+#  define FD_SETSIZE	64
+# endif
 #endif
 
 typedef unsigned long	__fd_mask;
diff --git a/winsup/cygwin/include/cygwin/version.h b/winsup/cygwin/include/cygwin/version.h
index 6f65a1299..a5d38f37a 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -517,12 +517,13 @@ details. */
        pthread_rwlock_clockrdlock, pthread_rwlock_clockwrlock,
        sem_clockwait, sig2str, str2sig.
   342: Remove cleanup_glue.
+  343: Change FD_SETSIZE and NOFILE.
 
   Note that we forgot to bump the api for ualarm, strtoll, strtoull,
   sigaltstack, sethostname. */
 
 #define CYGWIN_VERSION_API_MAJOR 0
-#define CYGWIN_VERSION_API_MINOR 342
+#define CYGWIN_VERSION_API_MINOR 343
 
 /* There is also a compatibity version number associated with the shared memory
    regions.  It is incremented when incompatible changes are made to the shared
diff --git a/winsup/cygwin/include/sys/param.h b/winsup/cygwin/include/sys/param.h
index 63de726e6..742599b8b 100644
--- a/winsup/cygwin/include/sys/param.h
+++ b/winsup/cygwin/include/sys/param.h
@@ -17,7 +17,9 @@
 /* Max number of open files.  The Posix version is OPEN_MAX.  */
 /* Number of fds is virtually unlimited in cygwin, but we must provide
    some reasonable value for Posix conformance */
-#define NOFILE		8192
+#if !defined NOFILE && defined OPEN_MAX
+# define NOFILE         OPEN_MAX
+#endif
 
 /* Max number of groups; must keep in sync with NGROUPS_MAX in limits.h */
 #define NGROUPS		NGROUPS_MAX
diff --git a/winsup/cygwin/release/3.4.0 b/winsup/cygwin/release/3.4.0
index f310912c9..08d28d510 100644
--- a/winsup/cygwin/release/3.4.0
+++ b/winsup/cygwin/release/3.4.0
@@ -25,6 +25,10 @@ What changed:
   the current directory as Linux does.
   Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html
 
+- The default values of FD_SETSIZE and NOFILE are now 1024 and 3200,
+  respectively.
+  Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html
+
 
 Bug Fixes
 ---------
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index 0149a027a..46dc028f1 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -33,6 +33,11 @@ Handle UDP_SEGMENT and UDP_GRO socket options.
 The stdio input functions no longer try again to read after EOF.
 </para></listitem>
 
+<listitem><para>
+The default values of FD_SETSIZE and NOFILE are now 1024 and 3200,
+respectively.
+</para></listitem>
+
 </itemizedlist>
 
 </sect2>
-- 
2.36.1

Re: [PATCH] Cygwin: redefine some macros for Linux compatibility

[Ken Brown]

On 7/6/2022 4:25 PM, Ken Brown wrote:
> Patch attached.
> 
> I wasn't sure whether the API bump was warranted for such a trivial change.  But 
> the fact is that some programs compiled prior to the patch will behave 
> differently if they are recompiled after the patch.  For example, emacs limits 
> the number of open subprocesses to FD_SETSIZE, so this number will change when 
> emacs is recompiled for Cygwin 3.4.0.  Is that a good enough reason to bump the 
> API?

Oh, wait a minute there's already been an API bump from 341 to 342, so I guess 
there's no need for another.  I could just add the FD_SETSIZE and NOFILE changes 
to the explanation for that bump.

Ken

Re: [PATCH] Cygwin: redefine some macros for Linux compatibility

[Corinna Vinschen]

On Jul  6 16:51, Ken Brown wrote:
> On 7/6/2022 4:25 PM, Ken Brown wrote:
> > Patch attached.
> > 
> > I wasn't sure whether the API bump was warranted for such a trivial
> > change.  But the fact is that some programs compiled prior to the patch
> > will behave differently if they are recompiled after the patch.  For
> > example, emacs limits the number of open subprocesses to FD_SETSIZE, so
> > this number will change when emacs is recompiled for Cygwin 3.4.0.  Is
> > that a good enough reason to bump the API?
> 
> Oh, wait a minute there's already been an API bump from 341 to 342, so I
> guess there's no need for another.  I could just add the FD_SETSIZE and
> NOFILE changes to the explanation for that bump.

Just bump.  It doesn't hurt.

The patch is fine.  I was going to say we should drop OPEN_MAX, too,
just as on Linux, but that would be wrong because we really use OPEN_MAX
as a limit.


Thanks,
Corinna


Idle musing:

We could think about dropping OPEN_MAX, too.  getdtablesize() and
sysconf(_SC_OPEN_MAX) could be implemented as requesting the rlimit_cur
value of getrlimit(RLIMIT_NOFILE), as in glibc.  Per the current Linux
source, the start values for RLIMIT_NOFILE are 1024 as soft, and 4096 as
hard limit...