[Still CC Marco]
On 3/22/2021 7:43 AM, Corinna Vinschen via Cygwin-patches wrote:
[CC Marco]
On Mar 22 08:07, Takashi Yano via Cygwin-patches wrote:
On Sun, 21 Mar 2021 17:44:27 +0900
Takashi Yano wrote:
On Sun, 21 Mar 2021 13:01:24 +0900
Takashi Yano wrote:
Takashi Yano (2):
Cygwin:
On 3/8/2021 2:09 PM, Achim Gratz wrote:
Brian Inglis writes:
It's normally a merge conflict which will not be satisfied by regular
commands to restore the working files to upstream.
So you're pulling on an unclean work tree? That's a no-no, either keep
your changes on a separate branch (that
linkat(olddirfd, oldpath, oldname, newdirfd, newname, AT_EMPTY_PATH)
is supposed to create a link to the file referenced by olddirfd if
oldname is the empty string. Currently this is done via the /proc
filesystem by converting the call to
linkat(AT_FDCWD, "/proc/self/fd/", newdirfd, newname,
If linkat(2) is called with AT_EMPTY_PATH on an AF_LOCAL or
AF_UNIX socket that is not a socket file, the current code calls
fhandler_disk_file::link in most cases. The latter expects to be
operating on a disk file and uses the socket's io_handle, which
is not a file handle.
Fix this by calling
If facl(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::facl in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling
If fchown(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchown in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling
If fstat(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fstat_fs. The latter expects to
be operating on a disk file and uses the socket's io_handle, which is
not a file handle.
Fix this by calling fstat_fs only if the fhandler_socket object is a
If fstatvfs(2) is called on an AF_LOCAL or AF_UNIX socket that is not
a socket file, the current code calls fhandler_disk_file::fstatvfs in
most cases. The latter expects to be operating on a disk file and
uses the socket's io_handle, which is not a file handle.
Fix this by calling
If fchmod(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchmod in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling
Several of the fhandler_socket_local and fhandler_socket_unix methods
that support system calls are written as though they are operating on
socket files unless the socket is an abstract socket. This patchset
(except for the last patch) attempts to fix this by checking whether
the fhandler is
I'm not sure if this patch is right. Should facl fail on all commands
or just on SETACL? If the command is GETACL, for example, should this
fail like fgetxattr(2) or should it succeed like fstat(2)?
Cygwin may be the only platform that supports both facl(2) and O_PATH,
so I guess we're on our
This is in the spirit of the Linux requirement that file operations
like fchmod(2), fchown(2), and fgetxattr(2) fail with EBADF on files
opened with O_PATH.
---
winsup/cygwin/sec_acl.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/winsup/cygwin/sec_acl.cc b/winsup/cygwin/sec_acl.cc
This was done for the fhandler_socket_local class in commits
3a2191653a, 141437d374, and 477121317d, but the fhandler_socket_unix
class was overlooked.
---
winsup/cygwin/fhandler.h | 1 +
winsup/cygwin/fhandler_socket_unix.cc | 24
2 files changed, 25
When a FIFO is opened, syscalls.cc:open always calls fstat on the
newly-created fhandler_fifo. This results from a call to
device_access_denied.
To speed-up this fstat call, and therefore the open(2) call, use
PC_KEEP_HANDLE when the fhandler is created. The resulting
conv_handle is retained
Previously, the call to get_file_attribute for FIFOs set the first
argument to NULL instead of the handle h returned by get_stat_handle,
thereby forcing the file to be opened for fetching the security
descriptor in get_file_sd(). This was done because h might have been
a pipe handle rather than a
The first patch fixes a bug, in which fstat on FIFOs sometimes used
pipe handles instead of file handles.
The second and third patches should improve the efficiency of fstat
and open on FIFOs.
Ken Brown (3):
Cygwin: define fhandler_fifo::fstat
Cygwin: fstat_helper: always use handle in call
Previously fstat on a FIFO would call fhandler_base::fstat.
The latter is not appropriate if fhandler_fifo::open has already been
called (and O_PATH is not set), for the following reason. If a FIFO
has been opened as a writer or duplexer, then it has an io_handle that
is a pipe handle rather
This reverts commit 76dca77f049271e2529c25de8a396e65dbce615d. That
commit was based on the incorrect assumption that get_stat_handle,
when called on a FIFO in fstat_helper, would always return a handle
that is safe to use for getting the file information.
That assumption is true in many cases
Commit 76dca77f04 had a careless blunder, so this patch reverts it.
Nevertheless, fstat(2) can be made more efficient on FIFOs, and I'm
working on a separate patchset to do this right. It's worth doing,
because every call to open(2) on a FIFO leads to a call chain
device_access_denied -->
On 1/30/2021 11:34 AM, Ken Brown via Cygwin-patches wrote:
This patch attempts to fix the problem reported here:
https://cygwin.com/pipermail/cygwin/2020-September/246362.html
See also the followup here:
https://cygwin.com/pipermail/cygwin/2021-January/247666.html
The problem, briefly
Allow check_reparse_point_target to recognize reparse points with
reparse tag IO_REPARSE_TAG_AF_UNIX. These are used in recent versions
of Windows 10 to represent AF_UNIX sockets.
check_reparse_point_target now returns PATH_REP on files of this type,
so that they are treated as known reparse
This patch attempts to fix the problem reported here:
https://cygwin.com/pipermail/cygwin/2020-September/246362.html
See also the followup here:
https://cygwin.com/pipermail/cygwin/2021-January/247666.html
The problem, briefly, is that on certain recent versions of Windows
10, including
The new header defines some Cygwin-specific limits, using private
names. It is included by include/limits.h.
For example, we now have
#define __OPEN_MAX 3200
in include/cygwin/limits.h and
#define OPEN_MAX __OPEN_MAX
in include/limits.h. The purpose is to hide implementation details
Replace all occurrences of OPEN_MAX_MAX by OPEN_MAX, and define the
latter to be 3200, which was the value of the former. In view of the
recent change to getdtablesize, there is no longer a need to
distinguish between these two macros.
---
winsup/cygwin/dtable.cc| 8
Now that getdtablesize always returns OPEN_MAX_MAX, we can simplify
sysconf(_SC_OPEN_MAX) and getrlimit(RLIMIT_NOFILE) to just use that
same constant instead of calling getdtablesize.
---
winsup/cygwin/resource.cc | 5 +
winsup/cygwin/sysconf.cc | 11 +--
2 files changed, 2
This patchset is an extension of the patch submitted here:
https://cygwin.com/pipermail/cygwin-patches/2021q1/011060.html
That patch is included as the first patch in this set. The change to
OPEN_MAX still needs testing to see if it has too much impact on the
performance of tcsh.
I've make a
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest possible value for a file descriptor."
The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we
now return that.
On 1/28/2021 5:28 PM, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 11:13 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 08:42, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin
On 1/28/2021 11:13 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 08:42, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 21:51, Ken Brown via Cygwin-patches
On 1/28/2021 11:07 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 08:42, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 21:51, Ken Brown via Cygwin-patches wrote:
According to the Linux man page for getdtablesize(3
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 21:51, Ken Brown via Cygwin-patches wrote:
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest pos
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest possible value for a file descriptor."
The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we
now return that.
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks even if it fails on
symlinks.
The reason for following POSIX rather than Linux is to make gnulib
report that fchmodat
On 1/27/2021 8:27 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 08:22, Ken Brown via Cygwin-patches wrote:
On 1/27/2021 7:40 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 26 16:30, Ken Brown via Cygwin-patches wrote:
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag
On 1/27/2021 7:40 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 26 16:30, Ken Brown via Cygwin-patches wrote:
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks
On 1/26/2021 4:30 PM, Ken Brown via Cygwin-patches wrote:
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks even if it fails on
symlinks.
The reason for following POSIX
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks even if it fails on
symlinks.
The reason for following POSIX rather than Linux is to make gnulib
report that fchmodat
On 1/25/2021 1:57 PM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 25 12:24, Ken Brown via Cygwin-patches wrote:
Following POSIX, ensure that ctime is updated if chown succeeds,
unless the new owner is specified as (uid_t)-1 and the new group is
specified as (gid_t)-1. Previously, ctime
Following POSIX, ensure that ctime is updated if chown succeeds,
unless the new owner is specified as (uid_t)-1 and the new group is
specified as (gid_t)-1. Previously, ctime was unchanged whenever the
owner and group were both unchanged.
Aside from POSIX compliance, this fix makes gnulib report
On 1/20/2021 1:00 PM, Ken Brown via Cygwin-patches wrote:
Following Linux, return ENOTTY on a bad file descriptor and also set
errno to ENOTTY.
Previously 0 was returned and errno was set to EBADF. Returning 0
violates the requirement in
https://man7.org/linux/man-pages/man3/ptsname_r.3.html
When .. is in the source path and the path prefix exists but is not a
directory, return ENOTDIR instead of ENOENT. This fixes a failing
gnulib test of realpath(3).
Addresses: https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00214.html
---
winsup/cygwin/path.cc | 4 +++-
This documents commit aec64798, "Cygwin: add flag to indicate reparse
points unknown to WinAPI".
---
winsup/cygwin/release/3.2.0 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/winsup/cygwin/release/3.2.0 b/winsup/cygwin/release/3.2.0
index 132d5c810..c18a848de 100644
---
On 1/15/2021 12:42 PM, Ken Brown via Cygwin-patches wrote:
This documents commit b951adce, "Cygwin: add flag to indicate reparse
points unknown to WinAPI".
Sorry, there's a mistake in the commit message. A corrected version is on the
way.
Ken
This documents commit b951adce, "Cygwin: add flag to indicate reparse
points unknown to WinAPI".
---
winsup/cygwin/release/3.2.0 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/winsup/cygwin/release/3.2.0 b/winsup/cygwin/release/3.2.0
index 132d5c810..c18a848de 100644
---
On 1/13/2021 3:56 AM, Corinna Vinschen via Cygwin-patches wrote:
Hi Ken,
Happy New Year, btw :)
Thanks, same to you!
Ken
This fixes a bug on 32-bit Cygwin that was introduced in commit
84252946, "Cygwin: fstatat, fchownat: support the AT_EMPTY_PATH flag".
Add a comment explaining why fstat should not be called.
Addresses: https://cygwin.com/pipermail/cygwin/2021-January/247399.html
---
winsup/cygwin/release/3.2.0
Traverse the fifo_client_handler list from the top down to try to
avoid copying.
---
winsup/cygwin/fhandler_fifo.cc | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index eff05d242..8b67037cb 100644
On 11/16/2020 7:08 AM, Corinna Vinschen wrote:
On Nov 14 09:16, Ken Brown via Cygwin-patches wrote:
Don't call cstrdup on NULL pointers.
---
winsup/cygwin/path.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/path.h b/winsup/cygwin/path.h
index
Don't call cstrdup on NULL pointers.
---
winsup/cygwin/path.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/path.h b/winsup/cygwin/path.h
index b94f13df8..0b3e72fc1 100644
--- a/winsup/cygwin/path.h
+++ b/winsup/cygwin/path.h
@@ -320,9 +320,11 @@ class
On 11/9/2020 11:25 AM, Jon Turney wrote:
On 08/11/2020 19:27, Ken Brown via Cygwin-patches wrote:
On 11/8/2020 1:52 PM, Jon Turney wrote:
On 08/11/2020 18:19, Ken Brown via Cygwin-patches wrote:
On 11/5/2020 2:47 PM, Jon Turney wrote:
+# temporary directory to be used for files created
On 11/8/2020 1:52 PM, Jon Turney wrote:
On 08/11/2020 18:19, Ken Brown via Cygwin-patches wrote:
On 11/5/2020 2:47 PM, Jon Turney wrote:
+# temporary directory to be used for files created by tests (as an absolute,
+# /cygdrive path, so it can be understood by the test DLL, which will have
On 11/5/2020 2:47 PM, Jon Turney wrote:
+# temporary directory to be used for files created by tests (as an absolute,
+# /cygdrive path, so it can be understood by the test DLL, which will have
+# different mount table)
+tmpdir = $(shell cygpath -ma $(objdir)/testsuite/tmp/ | sed -e
Replace the 'WCHAR pipe_name_buf[48]' class member by 'PWCHAR
pipe_name_buf', and allocate space for the latter as needed.
Change the default constructor to accommodate this change, and add a
destructor that frees the allocated space.
Also change get_pipe_name and clone to accommodate this
The return value is now -NaN.
This fixes a bug in the mingw-w64 code that was imported into Cygwin.
The fix is consistent with Posix and Linux. It is also consistent
with the current mingw-w64 code, with one exception: The mingw-w64
code sets errno to EDOM if the input is -NaN, but this appears
On 10/12/2020 2:02 PM, Ken Brown via Cygwin-patches wrote:
It looks to me like there's been a bug in the MSG_WAITALL support for
AF_INET and AF_LOCAL sockets ever since that support was first
introduced 13 years ago in commit 023a2fa7. If I'm right, MSG_WAITALL
has never worked.
This patch
On 10/13/2020 7:49 AM, Corinna Vinschen wrote:
On Oct 8 17:36, Ken Brown via Cygwin-patches wrote:
On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
I'm about to push these. Corinna, please check them when you return.
The only difference between v2 and v1 is that there are a few
On 10/13/2020 7:28 AM, Corinna Vinschen wrote:
> On Oct 4 12:49, Ken Brown via Cygwin-patches wrote:
>> A successful connection can be indicated by STATUS_SUCCESS or
>> STATUS_PIPE_CONNECTED.
>
> THanks for catching but... huh? How does Windows generate two different
> s
On 10/12/2020 2:02 PM, Ken Brown via Cygwin-patches wrote:
It looks to me like there's been a bug in the MSG_WAITALL support for
AF_INET and AF_LOCAL sockets ever since that support was first
introduced 13 years ago in commit 023a2fa7. If I'm right, MSG_WAITALL
has never worked.
This patch
It looks to me like there's been a bug in the MSG_WAITALL support for
AF_INET and AF_LOCAL sockets ever since that support was first
introduced 13 years ago in commit 023a2fa7. If I'm right, MSG_WAITALL
has never worked.
This patch fixes it. I'll push it in a few days if no one sees
anything
If MSG_WAITALL is set, recv_internal calls WSARecv or WSARecvFrom in a
loop, in an effort to fill all the scatter-gather buffers. The test
for whether all the buffers are full was previously incorrect.
---
winsup/cygwin/fhandler_socket_inet.cc | 2 +-
winsup/cygwin/fhandler_socket_local.cc | 2
On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
I'm about to push these. Corinna, please check them when you return.
The only difference between v2 and v1 is that there are a few more
fixes.
I'm trying to help get the AF_UNIX development going again. I'm
mostly working on the topic
A successful connection can be indicated by STATUS_SUCCESS or
STATUS_PIPE_CONNECTED. Previously we were checking only for the
latter.
---
winsup/cygwin/fhandler_socket_unix.cc | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc
---
winsup/cygwin/fhandler_socket_unix.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc
b/winsup/cygwin/fhandler_socket_unix.cc
index 429aa8a90..0ae7fe125 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@
If open_pipe is called with xchg_sock_info true, call recv_peer_info
in addition to send_sock_info.
---
winsup/cygwin/fhandler_socket_unix.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc
b/winsup/cygwin/fhandler_socket_unix.cc
I'm about to push these. Corinna, please check them when you return.
The only difference between v2 and v1 is that there are a few more
fixes.
I'm trying to help get the AF_UNIX development going again. I'm
mostly working on the topic/af_unix branch. But when I find bugs that
exist on master,
If __WITH_AF_UNIX is defined when Cygwin is built, then a named
AF_UNIX socket is represented by a reparse point with a
Cygwin-specific tag and GUID. Make such files recognizable as reparse
points (but not as sockets) even if __WITH_AF_UNIX is not defined.
That way utilities such as 'ls' and 'rm'
Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path
handling", changed check_reparse_point_target so that it could return
a positive value on a known reparse point that is not a symlink. But
some of the code in check_reparse_point that handles this positive
return value was executed
The following Windows system calls currently fail with
STATUS_IO_REPARSE_TAG_NOT_HANDLED when called on an AF_UNIX socket:
- NtOpenFile in get_file_sd
- NtOpenFile in set_file_sd
- NtCreateFile in fhandler_base::open
Fix this by adding the FILE_OPEN_REPARSE_POINT flag to those calls
when the
There are two Windows system calls that currently fail with
STATUS_IO_REPARSE_TAG_NOT_HANDLED when called on an AF_UNIX socket: a
call to NtOpenFile in get_file_sd and a call to NtCreateFile in
fhandler_base::open.
Fix this by adding the FILE_OPEN_REPARSE_POINT flag to those calls
when the file
I'll push these in a few days if no one sees anything wrong. Corinna,
please check them when you return.
Ken Brown (3):
Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed
Cygwin: fix handling of known reparse points that are not symlinks
Cygwin: always recognize AF_UNIX sockets as
If __WITH_AF_UNIX is defined when Cygwin is built, then a named
AF_UNIX socket is represented by a reparse point with a
Cygwin-specific tag and GUID. Make such files recognizable as reparse
points (but not as sockets) even if __WITH_AF_UNIX is not defined.
That way utilities such as 'ls' and 'rm'
Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path
handling", changed check_reparse_point_target so that it could return
a positive value on a known reparse point that is not a symlink. But
some of the code in check_reparse_point that handles this positive
return value was executed
On 9/24/2020 10:04 AM, Jon Turney wrote:
On 24/09/2020 00:52, Ken Brown via Cygwin-patches wrote:
This was added as a temporary measure in commit e18f7f99 because it
wasn't yet in the mingw-w64 headers. With one exception, it is now in
the current release of the headers (version 8.0.0), so we
This was added as a temporary measure in commit e18f7f99 because it
wasn't yet in the mingw-w64 headers. With one exception, it is now in
the current release of the headers (version 8.0.0), so we don't need
it in winlean.h. The exception is that VirtualAlloc2 is only declared
conditionally in ,
On 9/21/2020 3:25 PM, Jon Turney wrote:
Jon Turney (3):
Cygwin: avoid GCC 10 error with -Werror=parentheses
Cygwin: avoid GCC 10 error with -Werror=narrowing
Cygwin: avoid GCC 10 error with -Werror=narrowing
winsup/cygwin/fhandler_console.cc | 4 ++--
On 9/21/2020 3:22 PM, Jon Turney wrote:
On 18/09/2020 22:17, Ken Brown via Cygwin-patches wrote:
Do you have to run something to regen the docs, FAQ.html, and push to the web
site, or does it run periodically, so I can follow up to the OP and get feed
back from the responder?
No, sorry. I
On 9/18/2020 11:29 AM, Brian Inglis wrote:
On 2020-09-18 05:59, Ken Brown via Cygwin-patches wrote:
On 9/17/2020 10:53 PM, Brian Inglis wrote:
enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008;
add 8.1, exclude S mode, add Cygwin32 on ARM, specify 64 bit only AMD
On 9/17/2020 10:53 PM, Brian Inglis wrote:
enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008;
add 8.1, exclude S mode, add Cygwin32 on ARM, specify 64 bit only AMD/Intel
---
winsup/doc/faq-what.xml | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
On 9/17/2020 2:51 PM, Brian Inglis wrote:
Add linux-next cpuinfo flags for Intel TSX suspend load address tracking
instructions and AMD Secure Encrypted Virtualization with Encrypted State
---
winsup/cygwin/fhandler_proc.cc | 8
1 file changed, 8 insertions(+)
diff --git
On 9/17/2020 2:29 PM, Brian Inglis wrote:
Based on thread https://cygwin.com/pipermail/cygwin/2020-September/246318.html
enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008
---
winsup/doc/faq-what.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
On 9/8/2020 3:02 PM, Ken Brown via Cygwin-patches wrote:
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/p
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/path.cc | 9 +
1 file changed, 9 insertions(+)
diff --git
On 9/8/2020 12:50 PM, Ken Brown via Cygwin-patches wrote:
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/p
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/path.cc | 6 ++
1 file changed, 6 insertions(+)
diff --git
This fixes the assertion failure reported here:
https://sourceware.org/pipermail/cygwin/2020-September/246160.html
with a simple test case here:
https://sourceware.org/pipermail/cygwin/2020-September/246188.html
That test case now fails as follows, as on Linux:
$ ./proc_bug.exe
open: Not
The incoming path is allowed to have the form "$PID/fd/[0-9]*/.*"
provided the descriptor symlink points to a directory. Check that
this is indeed the case.
---
winsup/cygwin/fhandler_process.cc | 15 +++
1 file changed, 15 insertions(+)
diff --git
---
winsup/cygwin/sigproc.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
index 2a9734f00..47352c213 100644
--- a/winsup/cygwin/sigproc.cc
+++ b/winsup/cygwin/sigproc.cc
@@ -44,7 +44,11 @@ char NO_COPY
nprocs is the number of children, not the number of deceased children.
The incorrect comment used to apply to a variable nzombies. The
latter was removed in commit 8cb359d9 in 2004, but the comment was
never updated.
---
winsup/cygwin/sigproc.cc | 2 +-
1 file changed, 1 insertion(+), 1
Delete a client handler by swapping it with the last one in the list
instead of calling memmove.
---
winsup/cygwin/fhandler_fifo.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index b3c4c4a25..75c8406fe
Set errno = 0 at the beginning so that the debug_printf call at the
end doesn't report a nonzero errno left over from some other function
call.
---
winsup/cygwin/path.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index f3b9913bd..95faf8ca7
Ken Brown (2):
Cygwin: add header defining GCC exception codes
Cygwin: strace: ignore GCC exceptions
winsup/cygwin/exceptions.cc | 10 +-
winsup/cygwin/gcc_seh.h | 19 +++
winsup/utils/strace.cc | 8
3 files changed, 28 insertions(+), 9 deletions(-)
Include it in exceptions.cc instead of defining the exception codes
there.
---
winsup/cygwin/exceptions.cc | 10 +-
winsup/cygwin/gcc_seh.h | 19 +++
2 files changed, 20 insertions(+), 9 deletions(-)
create mode 100644 winsup/cygwin/gcc_seh.h
diff --git
Any C++ app that calls 'throw' on 64-bit Cygwin results in an
exception of type STATUS_GCC_THROW (0x20474343) generated by the C++
runtime. Don't pollute the strace output by printing information
about this and other GCC exceptions.
---
winsup/utils/strace.cc | 8
1 file changed, 8
On 8/20/2020 10:06 AM, Corinna Vinschen wrote:
Wouldn't it make sense to create a header defining the GCC status values
as in libgcc/unwind-seh.c and share this between exceptions.cc and
strace.cc?
Yes, thanks for the suggestion. New patch(es) on the way. I called the header
"gcc_seh.h".
Any C++ app that calls 'throw' on 64-bit Cygwin results in an
exception of type STATUS_GCC_THROW (0x20474343) generated by the C++
runtime. Don't pollute the strace output by printing information
about this and other GCC exceptions.
---
winsup/utils/strace.cc | 7 +++
1 file changed, 7
This is necessary in order to be consistent with the following comment
in the definition of _Unwind_RaiseException() in the GCC source file
libgcc/unwind-seh.c:
The exception handler installed in crt0 will continue any GCC
exception that reaches there (and isn't marked non-continuable).
Define the pseudo keyword 'fallthrough' in woutsup.h to support this.
---
winsup/cygserver/Makefile.in | 2 +-
winsup/cygserver/bsd_helper.cc | 2 +-
winsup/cygserver/bsd_mutex.cc | 2 +-
winsup/cygserver/woutsup.h | 2 ++
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git
Don't try to read from fifo_client_handlers that are in the fc_closing
state. Experiments have shown that this always yields
STATUS_PIPE_BROKEN, so it just wastes a Windows system call.
Re-order the values in enum fifo_client_connect_state to reflect the
new status of fc_closing.
---
Rename the existing set_state() to query_and_set_state() to reflect
what it really does. (It queries the O/S for the pipe state.) Add a
new set_state() method, which is a standard setter, and a
corresponding getter get_state().
---
winsup/cygwin/fhandler.h | 9 --
fhandler_fifo::take_ownership() is called from select.cc::peek_fifo
and fhandler_fifo::raw_read and could potentially block indefinitely
if something goes wrong. This is always undesirable in peek_fifo, and
it is undesirable in a nonblocking read. Fix this by adding a timeout
parameter to
1 - 100 of 157 matches
Mail list logo
