Currently, the buffer of 128KB is passed to GetConsoleProcessList().
This causes page fault in the select() loop for console due to:
https://github.com/microsoft/terminal/issues/18264
because the previous code calls GetConsoleProcessList() with large
buffer and PeekConsoleInput() with small buffer alternately.
With this patch, the minimum buffer size is used that is determined
by GetConsoleProcessList() with small buffer passed.
Addresses: https://cygwin.com/pipermail/cygwin/2024-December/256841.html
Fixes: 72770148ad0a ("Cygwin: pty: Prevent pty from changing code page of parent console.")
Reported-by: Steven Buehler <buehlersj@outlook.com>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 1a49c17840660bc0e493b7db2d9ce5289906049d)
Behave like sched_setparam() if the requested policy is identical
to the fixed value (SCHED_FIFO) returned by sched_getscheduler().
Fixes: 9a08b2c02eea ("* sched.cc: New file. Implement sched*.")
Signed-off-by: Christian Franke <christian.franke@t-online.de>
(cherry picked from commit 522f3e921aa034c6a146021a918ce8b479a9111e)
Previously, two bugs exist in sigtimedwait(). One is, that since
_my_tls.sigwait_mask was left non-zero if the signal arrives after
the timeout, sigpacket::process() would wrongly try to handle it.
The other is if a timeout occurs after sigpacket::process() is
called, but not completed yet, the signal handler can be called
accidentally. If the signal handler is set to SIG_DFL or SIG_IGN,
access violation will occur in both cases.
With this patch, in sigwait_common(), check if sigwait_mask == 0
to confirm that sigpacket::process() cleared it. In this case,
do not treat WAIT_TIMEOUT, but call cygwait() again to retrieve
the signal. Furthermore, sigpacket::process() checks whether
timeout occurs in sigwait_common() and if timeout already happens,
do not treat the signal as waited. In both cases, to avoid race
issues, the code is guarded by cygtls::lock().
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256762.html
Fixes: 24ff42d79aab ("Cygwin: Implement sigtimedwait")
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>
(cherry picked from commit 26144e4008cd8f7288f3387eea697bba4006e16f)
The following debug message occassionally shows up in strace output:
SetThreadName: SetThreadDescription() failed. 00000000 10000000
The HRESULT of 0x10000000 is not an error, rather the set bit just
indicates that this HRESULT has been created from an NTSTATUS value.
Use the IS_ERROR() macro instead of just checking for S_OK.
Fixes: d4689b99c686 ("Cygwin: Set threadnames with SetThreadDescription()")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
(cherry picked from commit 21a2c9db6952954608cdf92638b411b15e7606c6)
Currently, create_lock_obj() can create multiple locks with the same
lock range that have different version number. However, lf_setlock()
and lf_clearlock() cannot handle this case appropriately. With this
patch, make lf_setlock() and lf_clearlock() find overlap again even
when ovcase = 1 (lock and overlap have the same lock range).
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256750.html
Fixes: 2e560a092c1c ("* flock.cc (LOCK_OBJ_NAME_LEN): Change to accommodate extra lf_ver field.")
Reported-by: Sebastian Feld <sebastian.n.feld@gmail.com>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 8dee07a1f12682307be07e12a7fd8d5c8ecc1e2b)
The commit ae181b0ff122 has a bug that the pointer is referred bofore
NULL check in the function lf_clearlock(). This patch fixes that.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256750.html
Fixes: ae181b0ff122 ("Cygwin: lockf: Make lockf() return ENOLCK when too many locks")
Reported-by: Sebastian Feld <sebastian.n.feld@gmail.com>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit e7ef920d7d0dcff8cfe7a0c914f803b8c78900bb)
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Fixes: 28fa2a72f8106 ("* syscalls.cc (check_dir_not_empty): Check surplus directory entries")
Co-authored-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Bernhard Übelacker <bernhardu@mailbox.org>
(cherry picked from commit dbb8069df56cb68ea1167b3bc0ceb66fa6c35d3f)
Change the first parameter of pthread_sigqueue() to be a thread id rather
than a thread pointer. The change is to match the Linux implementation of
this function.
The user-visible function prototype is changed in include/pthread.h.
The pthread_sigqueue() function is modified to work with a passed-in thread
id rather than an indirect thread pointer as before. (It used to be
"pthread_t *thread", i.e., class pthread **.) The release note for Cygwin
3.5.5 is updated.
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Addresses: https://cygwin.com/pipermail/cygwin/2024-September/256439.html
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Fixes: 50350cafb375 ("* cygwin.din (pthread_sigqueue): Export.")
(cherry picked from commit 1e8c92e21d386d2e4a29fa92e8258979ff19ae6b)
This commit revises `pthread_cleanup_push` and `pthread_cleanup_pop`
macros to use a `do { ... } while(0)` wrapper, preventing syntax errors
when used in certain contexts. The original code could fail when they
are wrapped within a `do { ... } while(0)`, causing unintended behavior
or compilation issues.
Example of error:
#include <pthread.h>
#define pthread_cleanup_push_wrapper(_fn, _arg) do { \
pthread_cleanup_push(_fn, _arg); \
} while (0)
#define pthread_cleanup_pop_wrapper(_execute) do { \
pthread_cleanup_pop(_execute); \
} while (0)
void cleanup_fn (void *arg) {}
void *thread_func (void *arg)
{
pthread_cleanup_push_wrapper(cleanup_fn, NULL);
pthread_cleanup_pop_wrapper(1);
return NULL;
}
int main (int argc, char **argv) {
pthread_t thread_id;
pthread_create(&thread_id, NULL, thread_func, NULL);
}
This would fail due to unmatched braces in the macro expansion. The new
structure ensures the macro expands correctly in all cases.
Fixes: 007276b30e0a ("* cygwin.din: Add _pthread_cleanup_push and _pthread_cleanup_pop.")
Signed-off-by: Shaobo Song <shnusongshaobo@gmail.com>
Previously, the condition to clean up input/output mode was based
on wrong premise. This patch fixes that.
Fixes: 8ee8b0c974d7 ("Cygwin: console: Use GetCurrentProcessId() instead of myself->dwProcessId")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 30d266947842fec82cae9a190bc8b5bf2e108cd0)
The commit 90ddab98780d uses myself->dwProcessId to get windows pid.
However, it will be overridden in stub process if exec() is called.
With this patch, GetCurrentProcessId() instead of myself->dwProcessId.
Fixes: 90ddab98780d ("Cygwin: console: Re-fix open() failure on exec() by console owner")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 8ee8b0c974d723d618182fbbdeb1e9186b69c6f3)
Previous fix (commit df0953aa298c) fixes only a part of the problem.
Since exec() overrides the cygwin pid of the caller process, it makes
console owner handling complex. This patch makes console use Windows
pid as the owner pid (con.owner) instead of cygwin pid to make the
handling simpler.
Fixes: df0953aa298c ("Cygwin: console: Fix open() failure when the console owner calls exec().")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 90ddab98780da0e888ff09987d4651107c0f48d6)
Currently, open() tries to attach to the console which is owned by
the console owner process. However, when the owner process calls
exec(), AttachConsole() to dwProcessId may sometimes fail due to
unlucky timing. With this patch, open() tries to attach also to
exec_dwProcessId if attaching to dwProcessId fails. That is, open()
tries to attach to both the stub process and target process to
prevent the above situation.
Fixes: 3721a756b0d8 ("Cygwin: console: Make the console accessible from other terminals.")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, sigfe had a long-standing problem that the signal handler
destroys fpu states. This is caused by fninit instruction in sigdelayed.
With this patch, instead of fnstcw/fldcw and fninit, fnstenv/fldenv
are used to maintain fpu states.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256503.html
Fixes: ed89fbc3ff11 ("* gendef (sigdelayed (x86_64)): Save and restore FPU control word.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by:
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
The expression computing the next-less-power of 2 for the next write
when the pipe buffer is getting filled up allows negative shift values.
This works on Intel CPUs because the shift expression only evaluates the
5 LSBs, but it's undefined behaviour per the C standard. Use the
correct expression to get a positive shift value.
Fixes: 170e6badb621 ("Cygwin: pipe: improve writing when pipe buffer is almost full")
Reported-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
There was a long-standing issue that pseudo console ownership could
not hand over from the process whose ctty is /dev/cons* rather than
/dev/pty*. This problem happens when a cygwin app starts non-cygwin
app in a pty, then the non-cygwin app starts multiple cygwin apps,
and the non-cygwin app ends before the second cygwin apps end.
In this case, the stub process of the non-cygwin app hands over the
ownership of pcon to one of the second cygwin apps, however, this
app does not hand over the ownership of pcon to another second
cygwin app. This is due to the fact that the hand-over feature is
implemented only in fhandler_pty_slave but not in fhandler_console.
With this patch, the second cygwin apps check if their console device
is inside a pseudo console, and if so, it tries to hand over the
ownership of the pseudo console to anther process that is attached
to the same pseudo console.
Addresses: https://cygwin.com/pipermail/cygwin/2024-February/255388.html
Fixes: 253352e796ff ("Cygwin: pty: Allow multiple apps to enable pseudo console simultaneously.")
Reported-by: lmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>, Hossein Nourikhah <hossein@libreoffice.org>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, lockf() printed a warning message when the number of locks
per file exceeds the limit (MAX_LOCKF_CNT). This patch makes lockf()
return ENOLCK in that case rather than printing the warning message.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256528.html
Fixes: 31390e4ca643 ("(inode_t::get_all_locks_list): Use pre-allocated buffer in i_all_lf instead of allocating every lock. Return pointer to start of linked list of locks.")
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>
Previously, adding a new lock by lockf() over multiple existing locks
failed. This is due to a bug that lf_setlock() tries to create a lock
that has already been created. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256528.html
Fixes: a998dd705576 ("* flock.cc: Implement all advisory file locking here.")
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>
Fixed another precision bug in powf(). This one is in the computation
[t=p_l+p_h High]. We multiply t by lg2_h, and want the result to be
exact. For the bogus float case of the high-low decomposition trick, we
normally discard the lowest 12 bits of the fraction for the high part,
keeping 12 bits of precision. That was used for t here, but it doesnt't
work because for some reason we only discard the lowest 9 bits in the
fraction for lg2_h. Discard another 3 bits of the fraction for t to
compensate.
This bug gave wrong results like:
powf(0.9999999, -2.9999995) = 1.0000002 (should be 1.0000001)
hex values: 3F7FFFFF C03FFFFE 3F800002 3F800001
As explained in the log for the previous commit, the bug is normally
masked by doing float calculations in extra precision on i386's, but is
easily detected by ucbtest on systems that don't have accidental extra
precision.
Reference: 5f20e5ce7f
Original Author: Bruce Evans
(1) The bit for the 1.0 part of bp[k] was right shifted by 4. This
seems to have been caused by a typo in converting e_pow.c to
e_powf.c.
(2) The lower 12 bits of ax+bp[k] were not discarded, so t_h was
actually plain ax+bp[k]. This seems to have been caused by a logic
error in the conversion.
These bugs gave wrong results like:
powf(-1.1, 101.0) = -15158.703 (should be -15158.707)
hex values: BF8CCCCD 42CA0000 C66CDAD0 C66CDAD4
Fixing (1) gives a result wrong in the opposite direction
(hex C66CDAD8), and fixing (2) gives the correct result.
ucbtest has been reporting this particular wrong result on i386 systems
with unpatched libraries for 9 years. I finally figured out the extent
of the bugs. On i386's they are normally hidden by extra precision.
We use the trick of representing floats as a sum of 2 floats (one much
smaller) to get extra precision in intermediate calculations without
explicitly using more than float precision. This trick is just a
pessimization when extra precision is available naturally (as it always
is when dealing with IEEE single precision, so the float precision part
of the library is mostly misimplemented). (1) and (2) break the trick
in different ways, except on i386's it turns out that the intermediate
calculations are done in enough precision to mask both the bugs and
the limited precision of the float variables (as far as ucbtest can
check).
ucbtest detects the bugs because it forces float precision, but this
is not a normal mode of operation so the bug normally has little effect
on i386's.
On systems that do float arithmetic in float precision, e.g., amd64's,
there is no accidental extra precision and the bugs just give wrong
results.
Reference: 12be4e0d5a
Original Author: Bruce Evans
The decomposition needs to be into 12+24 bits of precision for extra-
precision multiplication, but was into 13+24 bits. On i386 with -O1 the
bug was hidden by accidental extra precision, but on amd64, in 2^32
trials the bug caused about 200000 errors of more than 1 ulp, with a
maximum error of about 80 ulps. Now the maximum error in 2^32 trials
on amd64 is 0.8573 ulps. It is still 0.8316 ulps on i386 with -O1.
The nearby decomposition of 1/ln2 and the decomposition of 2/(3ln2) in
the double precision version seem to be sub-optimal but not broken.
Reference: b4437c3d32
Original Author: Bruce Evans
timer_delete() always returned failure. This issue has been
detected by 'stress-ng --hrtimers 1'.
Fixes: 229ea3f23c015 ("Cygwin: posix timers: reimplement using OS timer")
Signed-off-by: Christian Franke <christian.franke@t-online.de>
If the parent process has already used pread() or pwrite(), these
functions fail with EBADF if used on the inherited fd. Ensure that
fix_after_fork() is called to invalidate the prw_handle. This issue
has been detected by 'stress-ng --pseek 1'.
Fixes: c36cd56c548a ("* fhandler.cc (fhandler_base::open): Drop local create_options variable.")
Signed-off-by: Christian Franke <christian.franke@t-online.de>
If a cygwin app is executed from a non-cygwin app and the cygwin
app exits, the read pipe remains in the non-blocking mode because
of the commit fc691d0246b9. Due to this behaviour, the non-cygwin
app cannot read the pipe correctly after that. Similarly, if a
non-cygwin app is executed from a cygwin app and the non-cygwin
app exits, the read pipe remains in the blocking mode. With this
patch, the blocking mode of the read pipe is stored into a variable
was_blocking_read_pipe on set_pipe_non_blocking() when the cygwin
app starts and restored on close(). In addition, the pipe mode is
set to non-blocking mode in raw_read() if the mode is blocking
mode by referring the variable is_blocking_read_pipe as well.
is_blocking_read_pipe is a member of fhandler_pipe class and is set
by set_pipe_non_blocking(), so if other process sets the pipe mode
to blocking mode, the current process cannot know the pipe is
blocking mode. Therefore, is_blocking_read_pipe is also set on the
signal __SIGNONCYGCHLD, which is sent to the process group when
non-cygwin app is started.
Addresses: https://github.com/git-for-windows/git/issues/5115
Fixes: fc691d0246b9 ("Cygwin: pipe: Make sure to set read pipe non-blocking for cygwin apps.");
Reported-by: isaacag, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>, Ken Brown <kbrown@cornell.edu>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
All three warnings produced with -Og are false positives.
But given we're using -Werror unconditionally it's better
to be safe than sorry.
Reported-by: Kevin Ushey <kevinushey@gmail.com>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
(cherry picked from commit 2a2a6486a089b90d05b258bd853d136f00cb7c69)
After the commit 7f3c22532577, writing to pipe extremely slows down.
This is because cygwait(select_sem, 10, cw_cancel) is called even
when write operation is already completed. With this patch, the
cygwait() is called only if the write operation is not completed.
Addresses: https://cygwin.com/pipermail/cygwin/2024-August/256398.html
Fixes: 7f3c22532577 ("Cygwin: pipe: handle signals explicitely in raw_write")
Reported-by: Jim Reisert AD1C <jjreisert@alum.mit.edu>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit f78009cb1ccf84cc343cf2441c76196461d87532)
When win32-input-mode (which is supported by Windows Termainal) is
set by "\033[?9001h", cons_master_thread does not work properly and
consumes larger and larger memory space. This is because sending
event by WriteConsoleInput() is translated into the sequence that
is used by win32-input-mode. Due to this behaviour, write-back
of the INPUT_RECORDs does not work as expected. With this patch,
cons_master_thread is disabled on win32-input-mode where the signal
keys such as Ctrl-C, Ctrl-Z etc. never comes.
Addresses: https://cygwin.com/pipermail/cygwin/2024-August/256380.html
Fixes: ff4440fcf768 ("Cygwin: console: Introduce new thread which handles input signal.")
Reported-by: Adamyg Mob <adamyg.mob@gmail.com>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
(cherry picked from commit 84d77e5918e18170c393407d477140fcf5d3e432)
nl_langinfo_l accesses lc_messages_T::codeset as soon as
__HAVE_LOCALE_INFO__ is defined, but codeset only exists
if __HAVE_LOCALE_INFO_EXTENDED__ is defined.
Fix this by defining lc_messages_T::codeset depending on
__HAVE_LOCALE_INFO__.
Fixes: ac7f1d5e931c ("Get rid of LCID, reformat type definitions in setlocale.h")
Reported-by: Inglis <Brian.Inglis@SystematicSW.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The nl_ext array contains offsets into the extended info of
locale structures, the index being equivalent to the nl_item
values in langinfo.h.
For the lc_messages_T struct, nl_ext erroneusly contains an
entry for the codeset member, which is in fact not part of the
extended info in nl_item. However, due to that, the offsets for
subsequent entries are off by one.
Fix this by dropping the messages::codeset entry from nl_ext.
Fixes: d47d5b850bed ("Extend locale support to maintain wide char values of native strings")
Reported-by: Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
If a nonblocking write requires short writes, just try it once
as in the blocking case. After all, we are nonblocking, so
don't loop unnecessarily.
Fixes: 170e6badb621 ("Cygwin: pipe: improve writing when pipe buffer is almost full")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
There's no reason to overwrite len1 with align if they are the same value.
Fixes: 170e6badb621 ("Cygwin: pipe: improve writing when pipe buffer is almost full")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far fhandler_pipe_fifo::raw_write always returns -1/EINTR
if a signal arrived. Linux does not do that if there's still
space left in the pipe buffer.
The Linux buffer handling can't be emulated by Cygwin, but we
can do something similar which makes it much more likely to still
write successfully even if the buffer is almost full.
Utilize pipe_data_available to return valid pipe buffer usage
to raw_write, allowing a more sophisticated way to fill the
buffer while maintaining comaptibility with non-Cygwin pipes.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Linux select(2) returns the pipe as writable if at least one
free page (4K onl most systems) is left in a page-oriented buffer
handling. This is the same as PIPE_BUF.
Emulate this behaviour by only returning the pipe as writable
if at least 4K space is left in the buffer.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The simple cygwait call in fhandler_pipe_fifo::raw_write doesn't
take the SA_RESTART setting into account. Move handling the
signal into raw_write.
Fixes: 4b25687ea3ee2 ("Cygwin: fhandler_pipe: add raw_read and raw_write")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This avoids a `__utoa undefined' warning when building newlib
for Cygwin. We still need to export the symbols for backward
compatibility.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Rewrite to avoid new use-after-free warnings about realloc(), seen with
gcc 12, e.g.:
> In function ‘void rebase_locale_buf(const void*, const void*, const char*, const char*, const char*)’,
> inlined from ‘int __set_lc_time_from_win(const char*, const lc_time_T*, lc_time_T*, char**, wctomb_p, const char*)’ at ../../../../src/winsup/cygwin/nlsfuncs.cc:705:25:
> ../../../../src/winsup/cygwin/nlsfuncs.cc:338:24: error: pointer ‘new_lc_time_buf’ may be used after ‘void* realloc(void*, size_t)’ [-Werror=use-after-free]
> 338 | *ptrs += newbase - oldbase;
> | ~~~~~~~~^~~~~~~~~
> ../../../../src/winsup/cygwin/nlsfuncs.cc: In function ‘int __set_lc_time_from_win(const char*, const lc_time_T*, lc_time_T*, char**, wctomb_p, const char*)’:
> ../../../../src/winsup/cygwin/nlsfuncs.cc:699:44: note: call to ‘void* realloc(void*, size_t)’ here
> 699 | char *tmp = (char *) realloc (new_lc_time_buf, len);
Technically, it's UB to later refer to the realloced pointer (even just
for offset computations, without deferencing it), so switch to using
malloc() to create the resized copy.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Fix gcc 12 warnings about narrowing conversions of socket ioctl constants
when used as case labels, e.g:
> ../../../../src/winsup/cygwin/net.cc: In function ‘int get_ifconf(ifconf*, int)’:
> ../../../../src/winsup/cygwin/net.cc:1940:18: error: narrowing conversion of ‘2152756069’ from ‘long int’ to ‘int’ [-Wnarrowing]
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
The _IOR anbd _IOW macros cast the sizeof of their third arg
uselessly to long. The _IO definitions have been taken from BSD
in 1995 and never changed again. The fact that the sizeof() gets
cast to long is probably a remnant from the past when the stuff
was supposed to be used on 16 bit machines, but the value was
supposed to be 32 bit.
Given that the values are not supposed to be ever bigger than 32 bit,
we drop the (long) cast. Compare with current FreeBSD, which does
not cast at all.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Fix a gcc 12 warning about a narrowing conversion in case labels for
tape options.
> In file included from /wip/cygwin/src/winsup/cygwin/include/sys/mtio.h:14,
> from ../../../../src/winsup/cygwin/fhandler/tape.cc:13:
> ../../../../src/winsup/cygwin/fhandler/tape.cc: In member function ‘int mtinfo_drive::set_options(HANDLE, int32_t)’:
> ../../../../src/winsup/cygwin/fhandler/tape.cc:965:12: error: narrowing conversion of ‘4026531840’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Fix a gcc 12 warning about an address known to be non-NULL in
format_proc_locale_proc().
> ../../../../src/winsup/cygwin/fhandler/proc.cc: In function ‘BOOL format_proc_locale_proc(LPWSTR, DWORD, LPARAM)’:
> ../../../../src/winsup/cygwin/fhandler/proc.cc:2156:11: error: the address of ‘iso15924’ will never be NULL [-Werror=address]
> 2156 | if (iso15924)
> | ^~~~~~~~
> ../../../../src/winsup/cygwin/fhandler/proc.cc:2133:11: note: ‘iso15924’ declared here
> 2133 | wchar_t iso15924[ENCODING_LEN + 1] = { 0 };
> | ^~~~~~~~
Fixes: c42b98bdc665f ("Cygwin: introduce /proc/codesets and /proc/locales")
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Fix warnings with gcc 12 about narrowing conversions of NTSTATUS
constants when used as case labels, e.g:
> ../../../../src/winsup/cygwin/exceptions.cc: In static member function ‘static int exception::handle(EXCEPTION_RECORD*, void*, CONTEXT*, PDISPATCHER_CONTEXT)’:
> ../../../../src/winsup/cygwin/exceptions.cc:670:10: error: narrowing conversion of ‘-1073741682’ from ‘NTSTATUS’ {aka ‘int’} to ‘unsigned int’ [-Wnarrowing]
See also: c5bdf60ac46401a51a7e974333d9622966e22d67
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
This disables a warning seen with gcc 12 caused by intrinsics used by
the inline implementation of NtCurrentTeb() inside w32api headers.
> In function ‘long long unsigned int __readgsqword(unsigned int)’,
> inlined from ‘_TEB* NtCurrentTeb()’ at /usr/include/w32api/winnt.h:10020:86,
> [...]
> /usr/include/w32api/psdk_inc/intrin-impl.h:838:1: error: array subscript 0 is outside array bounds of ‘long long unsigned int [0]’ [-Werror=array-bounds]
See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523#c6
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
