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. */
>
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
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.
>
>
> >
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 _control->state
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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:
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
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,
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
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
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:
-
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
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
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.
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
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
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
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
>
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
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
>
>
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
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
> > >
> > >
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
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:
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
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/
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
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:
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
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
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
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
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
>
>
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
52 matches
Mail list logo
