c8rtomb and mbrtoc8 not exported from libc

Hi, The Cygwin 3.5.0 announcement says that there are New API calls: c8rtomb, c16rtomb, c32rtomb, mbrtoc8, mbrtoc16, mbrtoc32. I have Cygwin 3.5.3 installed, and "nm /usr/lib/libc.a" shows that c16rtomb, c32rtomb, mbrtoc1

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi Yano, > The result is as follows (submitted as v4 patch). > > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag. > Similary, the next significant bit is used as destroyed flag. */ > con

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi Yano, > With v3 patch: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag */ > if (once_control->state & INT_MIN) > return 0; > // HERE: Point A. > /* The type of &once_control->

Re: SRW locks

Noel Grandin wrote: > > Still: Does ReleaseSRWLockExclusive notify other threads? > > > > Of course? How else would a lock work, it must release other waiters? > > It might not be a fair lock though, which is not a problem for this > situation, which does not require fair locking. > > > > Fun

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > With v3 patch: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag */ > if (once_control->state & INT_MIN) > return 0; > > /* The type of &once_control->sta

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > - // already done ? > - if (once_control->state) > + /* Sign bit of once_control->state is used as done flag */ > + if (once_control->state & INT_MIN) > return 0

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote: > > SRW locks are spin-locks. Since they are only pointer-sized, > > ReleaseSRWLockExclusive cannot notify other threads — unlike > > CRITICAL_SECTION. > > Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already > > held. > > > > No, they only spin briefly,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote in cygwin-patches: > Pardon my ignorance, but why not rather use the Windows SRWLock functionality? > https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks > > SRW locks are very fast, only require a single pointer-sized storage area, > can be stat

Re: multithreading broken in Cygwin 3.5.3

Takashi Yano wrote: > > My workaround implementation of pthread_once (in gnulib) looks like this: > > > > /* This would be the code, for > >typedef struct > > { > >pthread_mutex_t mutex; > >_Atomic unsigned int num_threads; > >_Atomic unsigned

Re: [PATCH] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > To avoid race issues, pthread::once() uses pthread_mutex. This caused > the handle leak which was fixed by the commit 2c5433e5da82. However, > this fix introduced another race issue, i.e., the mutex may be used > after it is destroyed. With this patch, do not

Re: multithreading broken in Cygwin 3.5.3

Takashi Yano wrote: > As you mentioned in private mail to me, this seems to be a regression of > pthread::once() introduced by > commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8. > > I'll submit a patch for that issue shortly. My workaround implementation of pthread_once (in gnulib) looks like thi

Re: newer version of mingw64-*-win-iconv ?

Brian Inglis wrote: > Ran playground local and CI builds of these packages at v0.0.8 successfully: > > https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv > https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv and https://cygwin.com/cgi-bin2/jobs

newer version of mingw64-*-win-iconv ?

Hi, It would be useful if someone could rebuild the two packages https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html based off the current git HEAD [1]. Reason: The current git HEAD is a reasonable alternative to GN

Re: an mbrtoc32 bug

The test case that I sent uses UTF-8 encoding. Here's another test case, that uses GB18030 (supposedly supported since Cygwin 3.5.0). It fails as well, in line 26. On glibc systems, this test works. #include #include #include #include #include #include #include int main () { assert (se

an mbrtoc32 bug

In Cygwin 3.5.3, the attached program has an assertion failure in line 24: bytes is not (size_t)-2. How to reproduce: $ gcc -Wall foo.c $ ./a I think this is a bug, because - ISO C 23 § 7.30.1.5 talks about "completing" a character, not "representing" an (entire) character. - The test pas

multithreading broken in Cygwin 3.5.3

Hi, In Cygwin 3.5.3, on different machines, I see 3 Gnulib tests failing by timeout that worked perfectly fine in Cygwin 3.4.6 and older: FAIL: test-call_once2.exe FAIL: test-lock.exe FAIL: test-pthread-once2.exe Find here attached a simplified version of test-pthread-once2.c. Compile and r

sethostname does not reject a too long hostname

The sethostname() system call is not standardized by POSIX, only by the LSB: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib-sethostname-2.html In particular, it should fail with EINVAL if "len is negative or larger than the maximum allowed size". In Cygwin 3.5.

Re: pagefile.sys is reported as being a directory

Hi Ken, > It turns out that this was a regression in 3.5.3 and was already > reported (in a slightly different form) in > >https://cygwin.com/pipermail/cygwin/2024-April/255812.html > > and fixed for 3.5.4. Thanks for the investigations! > > Do you have a workaround? In Gnulib we wish to

pagefile.sys is reported as being a directory

Hi, Ken Brown noticed this: pagefile.sys and swapfile.sys are being reported by Cygwin 3.5.3 as being directories. Cygwin 3.5.3 on Windows 10: $ ls -ld /proc/cygdrive/c/pagefile.* drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan 1 1601 /proc/cygdrive/c/pagefile.sys $ ls -ld /proc/cygdrive/c/

strverscmp is buggy in Cygwin 3.4.6

Hi, Here's a test case of strverscmp, from Dmitry Bogatov [1] #include int main () { return strverscmp ("UNKNOWN", "2.2.0") <= 0; } It succeeds on glibc and musl libc 1.2.4, but fails on musl libc 1.2.3 and Cygwin 2.9.0 and 3.4.6. The cause is apparently that Cygwin's strverscmp implementati

Re: rand is not ISO C compliant in Cygwin

Corinna Vinschen wrote: > Ok, I pushed a Cygwin-only patch for now, which calls Cygwin's random(3) > functions to implement rand(3), just as GLibC does it. Thanks! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:htt

Re: rand is not ISO C compliant in Cygwin

Corinna Vinschen wrote: > > My understanding of this paragraph is: > > - If an application wants 1., they can use rand_r with SEED pointing > > to a global variable. > > - If an application wants 2., they can use rand_r with SEED pointing > > to a per-thread variable. > > The problem I

Re: rand is not ISO C compliant in Cygwin

Corinna Vinschen wrote: > I took a look into POSIX and I'm a bit puzzled now. From > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html Part of the confusion is that POSIX and ISO C have slightly different wording. This POSIX page says: "The functionality described on this re

Re: random is not multithread-safe in Cygwin

Corinna Vinschen wrote: > > And indeed glibc, musl libc, AIX, Android, and even NetBSD implement it in a > > multithread-safe way. > > Our code is from FreeBSD, originally. I checked the latest code from > FreeBSD. It doesn't lock anything in random() and generates the same > error when running

Re: rand is not ISO C compliant in Cygwin

Corinna Vinschen wrote: > The rand() function would still not use locking but AFAICS that's > not actually required by POSIX or ISO C. Correct. Those who want an MT-safe rand-like function need to use random(), not rand(). Bruno -- Problem reports: https://cygwin.com/problems.html FAQ:

Re: rand is not ISO C compliant in Cygwin

Norton Allen wrote: > Cygwin/(newlib?) has chosen to avoid race conditions by making > pseudo-random sequences in different threads independent. Although the > standard does not require this, it does not prohibit it either. I disagree. I cited the relevant sentences from the standard. Other pla

rand is not ISO C compliant in Cygwin

ISO C 23 § 7.24.2.1 and 7.24.2.2 document how rand() and srand() are expected to behave. In particular: "The srand function uses the argument as a seed for a new sequence of pseudo-random numbers to be returned by subsequent calls to rand. If srand is then called with the same seed value, t

random is not multithread-safe in Cygwin

The function 'random' is, unlike 'rand', not marked as not MT-safe in POSIX [1][2]. Thus it must be multithread-safe [3]: "Each function defined in the System Interfaces volume of POSIX.1-2017 is thread-safe unless explicitly stated otherwise." And indeed glibc, musl libc, AIX, Android, and e

feraiseexcept does not raise traps in Cygwin

Hi, Seen on - Cygwin 3.4.6 or 2.9.0 on x86_64. - Cygwin 2.9.0 on i386. According to ISO C 23 § 7.6.4.3 "The feraiseexcept function attempts to raise the supported floating-point exceptions represented by its argument. 266) Footnote 266) The effect is intended to be similar to that of

Re: character class "alpha"

Brian Inglis wrote: > It seems to me that most application developers needing to support > non-Western-European languages might want a non-POSIX interpretation of > digits. Sure. GNU libunistring has dedicated API for this: - https://www.gnu.org/software/libunistring/manual/html_node/Object-o

Re: character class "alpha"

Corinna Vinschen wrote: > there are more of those expressions which are disabled on glibc and > fail on Cygwin, for instance in test-c32iscntrl.c. Maybe it's actually > the better idea to disable them on Cygwin, too, rather than to change > a working system... Sure. There is no standard how to ma

Re: character class "alpha"

Corinna Vinschen wrote: > I have a problem with the c32isalpha function. > > c32isalpha fails for the character U+FF11 FULLWIDTH DIGIT ONE, > because it expects the character to be an alphabetic character. This is not a big problem. You can see in the test-c32isalpha.c file that this test is disa

Re: GB18030 locale

Corinna Vinschen wrote: > However, on debugging this, I see it's totally broken. Trying to fix > this in the existing functions is futile. We need dedicated > support functions for GB18030, kind of like the FreeBSD functions, > just with extra support for surrogate pairs, as with our UTF8 stuff.

Re: GB18030 locale

Corinna Vinschen wrote: > test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. Hmm? When I read winsup/cygwin/release/3.5.0 and the commit 5da71b6059956a8f20a6be02e82867aa28aa3880, it seems the zh_CN.GB18030 locale (which on native Windows is called "Chinese_China.54936") should

Re: fnmatch improvements

Corinna Vinschen wrote: > > 1. cd testdir-fnmatch-posix > > ./configure > > grep REPLACE_FNMATCH config.status > > (Expected: REPLACE_FNMATCH is 0) > > $ grep REPLACE_FNMATCH config.status > S["REPLACE_FNMATCH"]="0" > > > make > > make check > > (Expected: No t

Re: fnmatch improvements

Corinna Vinschen wrote: > I'm puzzled because I'm an idiot. I forgot autoreconf. Things like that happen to me as well. There are so many generation phases (collect *.m4 files; autoconf; configure; make) that it's easy to forget one when making incremental changes. It's more reliable to regenerat

Re: fnmatch improvements

Corinna Vinschen wrote: > After the above fail, I tried from scratch with your below patch, > and I still get > > $ grep REPLACE_FNMATCH ./config.status > S["REPLACE_FNMATCH"]="1" > > Even though > > $ grep fnmatch log1 > checking for fnmatch.h... yes > checking for fnmatch... yes >

Re: fnmatch improvements

Corinna Vinschen wrote: > > > 4. cd testdir-fnmatch-posix > > > ./configure 2>&1 | tee log1 > > > make > > > make check > > I fixed the above problem and the POSIX check now works fine: Glad that the test suite was helpful (and that you fixed it before 3.5.0 — so, no additional c

Re: fnmatch improvements

Brian Inglis wrote: > It was added in C99 TR19769, integrated in C/++11 Yes. > available in libicu-devel: > > https://cplusplus.com/reference/cuchar/ > > https://open-std.org/jtc1/sc22/open/n3579.pdf > > https://open-std.org/jtc1/sc22/wg14/www/docs/n1326.pdf > > https:

fnmatch improvements

Hi, Gnulib has, for the first time, an fnmatch() implementation that supports characters outside the Unicode Basic Multilingual Plane (BMP), even on Cygwin with its 16-bits wchar_t type. That is, in an UTF-8 locale, e.g. fnmatch ("x?y", "x\360\237\230\213y", 0) now returns 0. This implementatio

Re: posix_spawn facility

Glenn wrote: > > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > > > > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > > > > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthr

Re: posix_spawn facility

Corinna Vinschen wrote: > > Hmm. Your code uses lpReserved2 for that, but the functionality is > > one implemented in MSVCRT. For obvious reasons, Cygwin executables > > are not linked against msvcrt.dll and we're using lpReserved2 for our > > own purposes. > > Oh, btw., did you know that there'

Re: posix_spawn_file_actions_add[f]chdir_np

Corinna Vinschen wrote: > I pushed the posix_spawnp patch for now, so all these tests PASS. > > See https://cygwin.com/cgit/newlib-cygwin/commit/?id=da40bd6eaf40 Cool! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Re: posix_spawn facility

Corinna Vinschen wrote: > Unfortunately you can't expect any noticable difference on Cygwin by > using posix_spawn. While Cygwin has a spawn() family of functions, we > don't (and can't... yet) use them. > > The problem is that we don't have a safe way to perform the spawn > attributes and file a

Re: posix_spawn facility

Eric Blake wrote: > POSIX issue now filed as > https://www.austingroupbugs.net/view.php?id=1674 Thank you very much! Note a typo: line 126541 is on page 3694 not on page 3594. Bruno -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Docum

Re: posix_spawn_file_actions_add[f]chdir_np

Hi Corinna, > Actually I had some spare time yesterday so I came up with an > implementation of posix_spawn_file_actions_addchdir_np and > posix_spawn_file_actions_addfchdir_np. It's pretty straightforward: > > https://cygwin.com/cgit/newlib-cygwin/commit/?id=7e03fc35f528 Yes, it's pretty strai

Re: posix_spawn facility

I wrote: > * posix_spawn_file_actions_addfchdir_np > implemented in glibc, musl libc Correction: posix_spawn_file_actions_addfchdir_np is implemented in glibc, musl libc, FreeBSD ≥ 13.1, macOS ≥ 10.15. Bruno -- Problem reports: https://cygwin.com/problems.html FAQ:

Re: posix_spawn facility

Eric Blake wrote: > we now have implementations in the wild that differ in behavior, and > use security as a reason for the divergence, it is worth getting that > clarified in POSIX. I'll file a bug against POSIX shortly For the reference, the systems that return ENOEXEC for posix_spawnp attempti

renameat2 works differently than on Linux

Hi, The renameat2 function is "Linux-specific", says the man page [1]; however, Cygwin implements it as well. In Cygwin 3.4.6, in a specific case, it operates differently than the Linux function. Namely, if the old* arguments and the new* arguments are the same and the flag RENAME_NOREPLACE is sp

ilogbl(NaN) is wrong

POSIX [1] specifies that the return value of the functions ilogbf(), ilogb(), ilogbl() for a NaN argument should all be the same, namely FP_ILOGBNAN. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/ilogb.html In Cygwin 3.4.6, the value of ilogbl(NaN) is not right. How to reproduce

wrong errno value set by readlinkat()

Hi, When an empty path argument is passed to the readlinkat() function, POSIX:2018 specifies that the function fails with error ENOENT: https://pubs.opengroup.org/onlinepubs/9699919799/functions/readlinkat.html "These functions shall fail if: ... [ENOENT] A component of path does not name an

Re: posix_spawn facility

Hi Corinna, > > Would it be possible to change Cygwin's posix_spawnp implementation, > > so that both tests succeed? > > Basically, yes, but... Thanks! > > Disclaimer: I have done my tests with Cygwin 2.9.0; so, if things have > >

posix_spawn facility

Hi, AFAIU, Cygwin has a working posix_spawn[p] implementation since 2020 (commit 3fbfcd11fb09d5f47af3043ee47ec5c7d863d872, 2020-08-03, Cygwin 3.1.7). Additionally, Gnulib has a posix_spawn[p] implementation since 2022, that works on all platforms, including native Windows. Based on it, I recommen