aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-03-25Fix GCN SIMD libm bugAndrew Stubbs1-2/+15
Since January, GCC has been miscompiling Newlib libm on AMD GCN due to undefined behaviour in the RESIZE_VECTOR macro. It was "working" but expanding the size of a vector would no longer zero the additional lanes, as it expected. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
2025-03-24Cygwin: document getlocalename_l fixesCorinna Vinschen1-0/+4
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-24getlocalename_l: allow LC_ALL categoryCorinna Vinschen2-3/+17
Following the changes from Austin Group bug https://www.austingroupbugs.net/view.php?id=1741, getlocalename_l() now allows to specify LC_ALL and returns a setlocale-conmpatible LC_ALL locale string. Consequentially we have to raise the size of _reent::_getlocalename_l_buf so there's enough space for the LC_ALL locale string. Guard all different definitions and usages of _getlocalename_l_buf in reent.h with _MB_CAPABLE. Link: https://www.austingroupbugs.net/view.php?id=1741 Fixes: 71511d4ac868 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-24locale: drop global_locale_string, add locale_string to locale_tCorinna Vinschen2-22/+29
After 71511d4ac868 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft") the Austin Group changed the definition of getlocalename_l() to return setlocale-compatible strings if LC_ALL has been specified. In contrast to the former definition which disallowed LC_ALL as category. In preparation, add a locale_string to every locale_t, and drop the static global_locale_string. This in turn requires to change currentlocale() to work locale-agnostic. Rename to __currentlocale and take two parameters, the locale object and a target string to store the locale string. The latter is required to allow specifiying a target string not in the current locale. Link: https://www.austingroupbugs.net/view.php?id=1741 Fixes: 71511d4ac868 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-24getlocalename_l: fix commentCorinna Vinschen1-1/+1
Fix name of the defining POSIX standard. Fixes: 71511d4ac868 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-24getlocalename_l: fix return value in LC_GLOBAL_LOCALE caseCorinna Vinschen1-2/+2
The data was written to the per-reent getlocalename buffer, but the value wasn't returned. Fixes: 71511d4ac868 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-24Cygwin: ntdll.h: enum _FILE_INFORMATION_CLASS: add FileKnownFolderInformationCorinna Vinschen1-0/+1
...for completeness. Introduced with Windows Server 2022. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-24Revert "Cygwin: CI: XFAIL umask03"Jon Turney1-5/+1
This reverts commit cbe7543cdfdb7f3d270214877d4a4c3e78710bd3.
2025-03-24CI: Remove inheritable permissions from working directoryJon Turney1-0/+3
Remove inheritable permissions from the working directory, since they break assumptions that the testsuite makes about the filemode a given umask will result in.
2025-03-24Cygwin: signal: Clear direction flag in sigdeleyedTakashi Yano2-0/+4
x86_64 ABI requires the direction flag in CPU flags register cleared. https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions However, currently that flag is not maintained in signal handler. Therefore, if the signal handler is called when that flag is set, it destroys the data and may crash if rep instruction is used in the signal handler. With this patch, the direction flag is cleared in sigdelayed() by adding cld instruction. Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257704.html Fixes: 1fd5e000ace5 ("import winsup-2000-02-17 snapshot") Reported-by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vischen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-24newlib: regenerate Makefile.inCorinna Vinschen1-1/+20
A new C file was added to the RISC-V build
2025-03-24newlib: riscv: Add stpcpy() portEric Salem4-45/+75
Add implementation of stpcpy() to the RISC-V port. Also refactor shared code between strcpy() and stpcpy() to a common function. Reviewed-by: Christian Herber <christian.herber@oss.nxp.com> Signed-off-by: Eric Salem <ericsalem@gmail.com>
2025-03-24newlib: riscv: Optimize strlen()Eric Salem2-12/+57
The RISC-V Zbb extension provides instructions optimized for bit operations. Use them when available for the RISC-V port. Reviewed-by: Christian Herber <christian.herber@oss.nxp.com> Signed-off-by: Eric Salem <ericsalem@gmail.com>
2025-03-24newlib: riscv: Add XLEN typedef and clean up typesEric Salem4-44/+45
The size of the long data type isn't precisely defined in the C standard, so create a new typedef that uses either uint32_t or uint64_t based on XLEN. The fixed width types are more robust against any ABI changes and fit the data types of the intrinsic functions. Use the new uintxlen_t type instead of long and uintptr_t. Reviewed-by: Christian Herber <christian.herber@oss.nxp.com> Signed-off-by: Eric Salem <ericsalem@gmail.com>
2025-03-21Cygwin: console: tty::restore really restores the previous modeTakashi Yano3-26/+32
Previously, tty::restore sets the console mode to a predetermined console mode that is widely common for many non-cygwin console apps. So, if a non-cygwin app that is started from cygwin process changes the console mode and executes cygwin sub-process, the console mode is changed to the predetermined mode rather than being restored the original mode that is set by the non-cygwin app. With this patch, the console mode is stored when a cygwin process is started from non-cygwin app, then tty::restore restores the previous console mode that is used by the previous non-cygwin app when the cygwin app exits. Addresses: https://github.com/msys2/msys2-runtime/issues/268 Fixes: 3312f2d21f13 ("Cygwin: console: Redesign mode set strategy on close().") Reported-by: Eu Pin Tien, Jeremy Drake <cygwin@jdrake.com> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-20Cygwin: doc: improve Solaris ACL documentationCorinna Vinschen1-10/+21
Document including cygwin/acl.h functions when using Solaris ACL functions. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-18Cygwin: bump DLL version to 3.7.0cygwin-3.7.0-devCorinna Vinschen1-1/+1
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-18Cygwin: doc: rename sched_setpolicy(2) to sched_setscheduler(2)cygwin-3.6.0Christian Franke1-2/+2
The function sched_setpolicy(2) does not exist. Fixes: 757424f74400 ("Cygwin: doc: document sched_setpolicy(2) and priority mapping") Signed-off-by: Christian Franke <christian.franke@t-online.de>
2025-03-18Cygwin: doc: clarify release message in terms of old NT4/Samba sharesCorinna Vinschen2-2/+2
Fixes: b9ed33dec0cb ("Cygwin: readdir: drop support for NT4/Win2K shares and Samba < 3.0.22") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-18Cygwin: Carry process affinity through to resultMark Geisert2-2/+13
Due to deficient testing, the current code doesn't return a valid result to users of sched_getaffinity(). The updated code carries the determined procmask through to the generation of result cpu mask. Recognize Windows' limitation that if the process is multi-group (i.e., has threads in multiple cpu groups) there is no visibility to which processors in other groups are being used. One could remedy this by looping through all the process' threads, but that could be expensive so is left for future contemplation. In addition, we'd have to maintain our own copy of each thread's current group and mask in internal overhead. (By the way, multi-group processes are only possible on Windows systems with more than 64 hardware threads.) Reported-by: Christian Franke <Christian.Franke@t-online.de> Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257616.html Signed-off-by: Mark Geisert <mark@maxrnd.com> Fixes: 641ecb07533e ("Cygwin: Implement sched_[gs]etaffinity()")
2025-03-17fix native symlink spawn passing wrong arg0Chris Denton1-1/+3
Currently when starting a process from bash via a native symlink, argv[0] is set to the realpath of the executable and not to the link name. This patch fixes it so the path of the symlink is seen instead. The cause is a path conversion in perhaps_suffix which follows native symlinks. Hence the fix this patch uses is to add PC_SYM_NOFOLLOW_REP when calling path_conv::check to prevent that. Fixes: be371651146c ("* path.cc (path_conv::check): Don't follow reparse point symlinks if PC_SYM_NOFOLLOW_REP flag is set.") Signed-off-by: Chris Denton <chris@chrisdenton.dev>
2025-03-14Cygwin: don't export arc4random_addrandom/arc4random_stirCorinna Vinschen2-5/+2
Keep the functions for backward compatibility, but don't export them from libcygwin.a for new applications. Drop the workaround from commit ad29c33229e5 ("Cygwin: stdlib.h: revert declaring arc4random_stir() as function"). Fixes: ad29c33229e5 ("Cygwin: stdlib.h: revert declaring arc4random_stir() as function") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-14newlib: fix uninitialized character count being used when printing float ↵Igor Petrov2-0/+2
without "_printf_float" being linked Patch fixes wrong number of written characters being returend from 'printf' family of functionsx when '_printf_float' is not linked (nano.specs). If user tries to print a floating point number anyway, returned number of written characters is not correct. For example in printf("%d%f", 1, 1.0); should return 1, but actaully returns 2.
2025-03-15Cygwin: signal: Remove context_copy in call_signal_handler()Takashi Yano1-2/+1
After the commit 1d97f8aa4385, context_copy in call_signal_handle() is not used anymore. This patch removes it. Fixes: 1d97f8aa4385 ("Cygwin: signals: don't evaluate SA_SIGINFO context after handler returns") Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-15Cygwin: signal: Use context locally copied in call_signal_handler()Takashi Yano1-19/+22
If the signal handler is called from inside of another signal handler, _cygtls::context may be destroyed by call_signal_handler() newly called. To avoid this situation, this patch used context locally copied in call_signal_handler(). Addresses: https://cygwin.com/pipermail/cygwin-patches/2025q1/013483.html Fixes: 9043956ce859 ("Only construct ucontext for SA_SIGINFO signal handlers") Reported-by: Takashi Yano <takashi.yano@nifty.ne.jp> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-15Cygwin: signal: Do not send __SIGFLUSHFAST if the pipe/queue is fullTakashi Yano1-1/+48
If __SIGFLUSHFAST is sent while the signal queue or the pipe is full, it causes deadlock. The mechanism is as follows. When sending __SIGFLUSHFAST, sig_send() waits for response (wakeup event) from wait_sig(). Therefore, the main thread does not process signals while waiting the wakeup event. However, if main thread does not process signals, signals in the queue are not dequeued. As a result, the sigpacket for __SIGFLUSHFAST stays in the signal pipe and not being processed. Thus the wakeup event will never be triggered. This did not occur with old signal queue design, because the queue never becomes full. This patch use alternative way for flushing the queue if the queue and the pipe is full, i.e., sending a event to trigger flushing in wait_sig(). Do the same for __SIGFLUSH as well. Addresses: https://cygwin.com/pipermail/cygwin-patches/2025q1/013461.html Fixes: 8ac22f8f16a8 ("Cygwin: signal: Redesign signal queue handling") Reported-by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-15Cygwin: signal: Ignore SIGSTOP while process is already stoppingTakashi Yano1-1/+4
On Linux, SIGSTOP while the process is stopping is ignored. With this patch, SIGSTOP is processed as a success with no effect while the process is already stopping. Fixes: 8f8eeb70ba73 ("* exceptions.cc (sigpacket::process): ...") Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-15Cygwin: signal: Do not clear signals in the queueTakashi Yano1-15/+1
Currently, sigpacket::process() clears some signals from the queue. For instance, SIGSTOP clears SIGCONT and SIGCONT clears SIGSTOP, etc. These might be needed by previous queue design, however, new queue design does not require that. On the contrary, that causes signal lost. With this patch, these sig_clear() calls are removed. Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257582.html Fixes: 1fd5e000ace5 ("import winsup-2000-02-17 snapshot") Reported-by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-15Cygwin: signal: Redesign signal queue handlingTakashi Yano2-23/+105
The previous implementation of the signal queue behaves as: 1) Signals in the queue are processed in a disordered manner. 2) If the same signal is already in the queue, new signal is discarded. Strictly speaking, these behaviours do not violate POSIX. However, these could be a cause of unexpected behaviour in some software. In Linux, some important signals such as SIGSTOP/SIGCONT do not seem to behave like that. This patch prevents SIGKILL, SIGSTOP, SIGCONT, and SIGRT* from that issue. Moreover, if SA_SIGINFO is set in sa_flags, the signal is treated almost as the same. Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257582.html Fixes: 7ac6173643b1 ("(pending_signals): New class.") Reported by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vinschen <corinna@vinschen.de>, Christian Franke <Christian.Franke@t-online.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-14Cygwin: signals: pop return address from signal stack earlierTakashi Yano3-32/+49
Commit a942476236b5 ("Cygwin: sigdelayed: pop return address from signal stack earlier") failed to take two facts into account: - _cygtls::call_signal_handler() potentially needs the return address as well, and - the signal handler may be interrupted by another signal. Revert the change in sigdelayed() and handle the signal stack manipulation in _cygtls::call_signal_handler() instead. Given we're poping the latest addresses from the signal stack early, there's no need for a big signal stack anymore. Reduce the size of the stack to 4 entries, plus one dummy entry. Move _cygtls::pop() from assembler to C++ code and make sure that stackptr neither underflows nor overflows the signal stack. Fixes: a942476236b5 ("Cygwin: sigdelayed: pop return address from signal stack earlier") Co-authored-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp> Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-13Cygwin: stdlib.h: revert declaring arc4random_stir() as functionCorinna Vinschen1-3/+3
The idea to define arc4random_stir() as macro to avoid autoconf problems in commit a8891c932192 ("Cygwin: stdlib.h: resurrect arc4random_stir() definition") worked fine for OpenSSH, but not for libbsd. During the build process the macro shadows the definition of arc4random_stir() and results in an error message like this: error: macro "arc4random_stir" passed 1 arguments, but takes just 0 Give up and just declare arc4random_stir() in a compatible way with libbsd again. Fixes: a8891c932192 ("Cygwin: stdlib.h: resurrect arc4random_stir() definition") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-12Cygwin: sigdelayed: pop return address from signal stack earlierCorinna Vinschen2-6/+22
When a signal handler is called via sigdelayed, sigdelayed pops the original address to return to from the signal stack. It only does so after the signal handler has been called and returned. If the signal handler never returns, for instance because it calls longjmp or setcontext, the address stays on the signal stack and the stack loses one slot. Given the stack has a depth of 256 entries, no signal handler will be called after 256 signal handlers long jumping out. Pop the return address from the signal stack prior to calling the signal handler and store it in a callee-saved register. This avoids filling up the signal stack in a scenario like this. Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257648.html Fixes: 61522196c715 ("* Merge in cygwin-64bit-branch.") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-12posix_spawn: skip SIGKILL & SIGSTOPYuyi Wang1-0/+2
sigaction() returns EINVAL on SIGKILL & SIGSTOP. We need to skip them. Fixes: c7c1a1ca1b33 ("* libc/posix/posix_spawn.c: New file.")
2025-03-11Cygwin: faq: fix supported windows version claimCorinna Vinschen1-5/+5
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-10Cygwin: signals: don't evaluate SA_SIGINFO context after handler returnsCorinna Vinschen1-8/+0
After return from a signal handler created with the SA_SIGINFO flag, Cygwin checks if the handler changed the context. If so, Cygwin erroneously uses the context in a call to setcontext(). Drop this special behaviour. Neither Linux man pages, nor POSIX documentation treat the context pointer given to the handler as anything other than a read-only area. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-10Revert "Cygwin: signals: make setcontext work from signal handlers"Corinna Vinschen1-1/+0
This reverts commit c5f9eed1c045ad05e968c9a9b8fb22b1d46cd8ea. This was the wrong thing to do because it leads to signal handling not working after swapcontext. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-10Cygwin: exceptions: drop setting ContextFlags when calling RtlCaptureContextCorinna Vinschen1-2/+0
RtlCaptureContext always returnes a CONTEXT_FULL type context anyway. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-08Cygwin: sched_setaffinity: fix EACCES if pid of other process is usedChristian Franke2-1/+4
GetProcessGroupAffinity() requires PROCESS_QUERY_LIMITED_INFORMATION. Fixes: 641ecb07533e ("Cygwin: Implement sched_[gs]etaffinity()") Signed-off-by: Christian Franke <christian.franke@t-online.de>
2025-03-06Cygwin: signal: Add one more guard to stop signal handling on exit().Takashi Yano1-1/+1
The commit 3c1308ed890e adds a guard to stop signal handling on exit() in call_signal_handler(). However, the signal that is already queued but does not use signal handler may be going to process even with that patch. This patch add one more guard at the begining of sigpacket::process() to avoid that situation. Fixes: 3c1308ed890e ("Cygwin: signal: Fix a problem that process hangs on exit") Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-06Cygwin: pipe: Fix 'lost connection' issue in scpTakashi Yano2-8/+23
When transferring huge file using scp, the "lost connection" error sometimes happen. This is due to fhandler_pipe_fifo::raw_write() accidentally sends data that is not reported in th return value when interrupted by a signal. The cause of the problem is that CancelIo() responds success even if NtWriteFile() already sends the data. The following testcase using plain Win32 APIs reproduces the issue. The output will be something like: W: 8589934592 R: 9280061440 Much more data was received than the sender thought it had sent. #include <windows.h> #include <stdio.h> DWORD WINAPI read_thread(LPVOID arg) { char buf[32768]; ssize_t sum = 0; HANDLE pr = (HANDLE) arg; while (1) { DWORD nb; BOOL res = ReadFile(pr, buf, sizeof(buf), &nb, NULL); if (!res) break; sum += nb; } printf("R: %lld\n", sum); } int main() { const char pipename[] = "\\\\.\\pipe\\testpipe"; char buf[65536*4] = {0,}; OVERLAPPED ov = {0,}; ssize_t sum = 0; HANDLE pw = CreateNamedPipe(pipename, PIPE_ACCESS_OUTBOUND | FILE_FLAG_OVERLAPPED, PIPE_TYPE_BYTE, 1, 65536, 0, 0, NULL); HANDLE pr = CreateFile(pipename, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); HANDLE thr = CreateThread(NULL, 0, read_thread, pr, 0, NULL); ov.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); int cnt = 0; while (sum < 8192LL*1024*1024) { DWORD nb; BOOL res = WriteFile(pw, buf, sizeof(buf), &nb, &ov); if (res) sum += nb; else if (GetLastError() == ERROR_IO_PENDING) { if ((cnt & 3) == 0) CancelIo (pw); res = GetOverlappedResult(pw, &ov, &nb, TRUE); if (!res && GetLastError() != ERROR_OPERATION_ABORTED) { printf("%08x\n", GetLastError()); break; } sum += nb; } cnt++; } printf("W: %lld\n", sum); CloseHandle(pw); CloseHandle(ov.hEvenet); WaitForSingleObject(thr, INFINITE); CloseHandle(pr); return 0; } It seems that CancelIo() works as expected when the NtWriteFile() is stucked on the pipe full. If the writing is on-going, CancelIo() reports cancelled, but the data may already be written. To avoid this issue, this patch waits for completion of writing a while before issuing CancelIo(), and if it has not completed yet, call CancelIo(). The wait is done using existing cygwait(select_sem, 10, cw_cancel). If the semaphore select_sem is released in the read side, the write operation will be on-going. Otherwise, the write operation is still stucking, so CancelIo() can safely cancel the I/O. Addresses: https://cygwin.com/pipermail/cygwin/2025-January/257143.html Fixes: 4003e3dfa1b9 ("Cygwin: pipes: always terminate async IO in blocking mode") Reported-by: Jay M Martin <jaymmartin_buy@cox.net> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-05sys/unistd.h: fix definition of setproctitle_initCorinna Vinschen1-1/+1
setproctitle_init is defined in c2x manner, omitting names for the unused parameters. This can result in warnings or errors on certain compiler versions: clang 8: error: parameter name omitted clang 15: warning: omitting the parameter name in a function definition is a C2x extension [-Wc2x-extensions] gcc -Wsystem-headers -pedantic -std=c17: warning: ISO C does not support omitting parameter names in function definitions before C2X [-Wpedantic] Add parameters to avoid above warning and errors. Fixes: 2e7f7b96e5f1 ("Cygwin: implement setproctitle") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-04Cygwin: stdlib.h: resurrect arc4random_stir() definitionCorinna Vinschen1-0/+5
An autoconf test for arc4random_stir() succeeds on Cygwin, because we export the symbol for backward compatibility. However, when building with -Werror afterwards, the definition of arc4random_stir() is missing in the stdlib.h header, so there's a chance to encounter an error like this with newer GCC: sshd.c:1113:25: error: implicit declaration of function ‘arc4random_stir’; did you mean ‘arc4random_buf’? [-Wimplicit-function-declaration] 1113 | arc4random_stir(); | ^~~~~~~~~~~~~~~ | arc4random_buf This occurs for instance when building OpenSSH 9.9p2 with GCC 15.0. Define arc4random_stir() as an empty macro in cygwin/stdlib.h to avoid the above compiler warning. Do not define arc4random_addrandom() yet, in the hope that this function call is really, really not used anymore. Fixes: 1cca343e4714 ("Drop redundant arc4random prototypes from cygwin/stdlib.h") Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2025-03-04Cygwin: signal: Fix a problem that process hangs on exitTakashi Yano1-1/+1
The process that receives many SIGSTOP/SIGCONT signals sometimes hangs on exit in sig_dispatch_pending(). This patch skips processing signals in call_signal_handler() when exit_state > ES_EXIT_STARTING to avoid that situation. Addresses: https://cygwin.com/pipermail/cygwin/2025-February/257473.html Fixes: d243e51ef1d3 ("Cygwin: signal: Fix deadlock between main thread and sig thread") Reported-by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-04Cygwin: signal: Fix a race issue on modifying _pinfo::process_stateTakashi Yano7-19/+23
The PID_STOPPED flag in _ponfo::process_state is sometimes accidentally cleared due to a race condition when modifying it with the "|=" or "&=" operators. This patch uses InterlockedOr/And() instead to avoid the race condition. Addresses: https://cygwin.com/pipermail/cygwin/2025-February/257473.html Fixes: 1fd5e000ace55 ("import winsup-2000-02-17 snapshot") Reported-by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-04Cygwin: signal: Fix deadlock on SIGCONTTakashi Yano1-10/+15
If SIGCONT starts processing while __SIGFLUSHFAST is ongoing, _main_tls->current_sig will never be cleared because the signal processing is stopped while waiting for the wake-up event in the main thread. This leads to a deadlock in the while loop waiting for current_sig to be cleared. With this patch, the function returns to wait_sig() if current_sig is set, rather than waiting for it in the while loop. Addresses: https://cygwin.com/pipermail/cygwin/2025-February/257473.html Fixes: 9d2155089e87 ("(sigpacket::process): Call handle_SIGCONT early to deal with SIGCONT.") Reported-by: Christian Franke <Christian.Franke@t-online.de> Reviewed-by: Corinna Vinschen <corinna@vinschen.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-03-03Silence -Woverflow warning in arc4random.cJan Dubiec1-3/+3
This patch fixes "integer overflow" warning in arc4random.c. It explicitly casts REKEY_BASE macro to size_t. The existing code relies on an implicit conversion to int and assumes that sizeof(int)=sizeof(size_t), which is not always true. 2025-03-02 Jan Dubiec <jdx@o2.pl> newlib/ChangeLog: * libc/stdlib/arc4random.c (REKEY_BASE): Explicitly cast the macro to size_t. newlib/libc/stdlib/arc4random.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
2025-03-03Silence -Wshift-count-overflow warningsJan Dubiec3-5/+6
This patch fixes a few "left shift count >= width of type [-Wshift-count-overflow]" warnings. Before shifting a char 16 (or more) bits left first it explicitly casts the char to uint32_t. The existing code relies on implicit casts to int and assumes that ints are 32-bit. This is not always true because the C standard does not require int to be 32-bit and there are targets (e.g. H8/300) where by default int is indeed 16-bit. 2025-03-02 Jan Dubiec <jdx@o2.pl> newlib/ChangeLog: * libc/stdlib/gdtoa-gdtoa.c (gdtoa): Cast to __ULong before left shift. * libc/string/memmem.c (memmem): Cast to uint32_t before left shift. * libc/string/strstr.c (strstr2): Ditto. (strstr3): Ditto. (strstr4): Ditto. newlib/libc/stdlib/gdtoa-gdtoa.c | 2 +- newlib/libc/string/memmem.c | 3 ++- newlib/libc/string/strstr.c | 6 +++--- 3 files changed, 6 insertions(+), 5 deletions(-)
2025-03-03H8/300: Silence -Wold-style-definition warningsJan Dubiec2-6/+3
2025-03-02 Jan Dubiec <jdx@o2.pl> newlib/ChangeLog: * libc/sys/h8300hms/sbrk.c: Replace the K&R definition with the standard one. * libc/sys/h8300hms/syscalls.c (_isatty): Ditto. (_unlink): Ditto. newlib/libc/sys/h8300hms/sbrk.c | 3 +-- newlib/libc/sys/h8300hms/syscalls.c | 6 ++---- 2 files changed, 3 insertions(+), 6 deletions(-)
2025-03-03Cygwin: console: Redesign mode set strategy on close().Takashi Yano2-25/+32
The required console mode for a non-cygwin process is different from that for a cygwin process. There are currently three modes: tty::cygwin, tty::native, and tty::restore. The latter two are for the non-cygwin processes. tty::restore is the mode for the non-cygwin processes that started the cygwin process, used to restore the previous behaviour. tty::native is the mode that reflects some terminfo flags. The issue below is caused because the console mode fails to be restored to the previous console mode used by cmd.exe. This patch redesigns the strategy to determine which mode should be set on console close() to fix all similar problems. Previously, the number of handle count is used to determine the appropriate console mode. However, the handle count seems uncertain for that purpose. In the new design, the relation ship between the master process and the process that is about to close the console is mainly used. This can provide more certain result than previous one. Addresses: https://github.com/microsoft/git/issues/730 Fixes: 30d266947842 ("Cygwin: console: Fix clean up conditions in close()") Reported-by: Mike Marcelais, Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
2025-02-27Cygwin: fix gcc-15 const warningsCorinna Vinschen1-3/+3
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
generated by cgit v1.1 at 2025-04-13 18:35:02 +0000