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

ave received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. */ /* Written by Bruno Haible , 2023. */ /* Whether to help the scheduler through explicit yield(). Uncomment this to see if the operating system has a fair sch

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

Re: ilogbl(0.0L) value is wrong

Hi Corinna, > I pushed this patch: > > https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=29ba52da9553 > > Please test the latest developer snapshot from https://cygwin.com/snapshots/ I can't test it easily. But the code looks good; only the comments could be improved; patch atta

ilogbl(0.0L) value is wrong

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

strtold does not set errno when it should

POSIX [1] makes it clear that when the value to be returned would cause underflow, it should set errno to ERANGE. [1] This test case fails with error code 4 on Cygwin 2.9. == foo.c ==

Re: iswcntrl() regression

Hello Thomas, Oops 1: I forgot to add the reference to POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/iswcntrl.html Oops 2: The relevant expression is iswcntrl (WEOF), not iswcntrl (EOF). > > Are there any other special requirements concerning EOF? WEOF is a special value. The

iswcntrl() regression

Hi, POSIX [1] requires that iswcntrl (EOF) == 0. This was true in CYGWIN_NT-10.0 2.9.0(0.318/5/3) (x86_64) but is no longer true in CYGWIN_NT-10.0 2.11.1(0.329/5/3) (x86_64). (Reported by Assaf Gordon.) Looking at the changes that occurred in the cygwin git between 2.9.0 (on 2017-08-03)

setting TZ is harmful

Hi, Currently, all commands in a Cygwin command window are run with the TZ environment variable set. It is set by /etc/profile.d/tzset.sh (or its csh equivalent, /etc/profile.d/tzset.csh). Setting TZ is harmful in two ways: 1) When the user changes the time zone (through the Windows Control P

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

Brian Inglis wrote in https://cygwin.com/ml/cygwin/2016-11/msg00259.html: > Have you got LT_CYGPATH pointing to cygwin32 cygpath Thanks for the suggestion, but alas: - There is no cygwin32 cygpath in /usr/i686-pc-cygwin/sys-root/usr/bin. - Letting LT_CYGPATH point to /usr/bin/cygpath.exe or C:

difference between cygwin32 and cygwin64 mounts breaks libtool

Hi, Short summary: == When a user has installed cygwin64 and the cross-compilation environment for compiling to 32-bit cygwin (i686-pc-cygwin-gcc et al.), then building (with --host=i686-pc-cygwin) a package that creates a shared library and a program that uses this shared library - i

Re: cygwin started speaking German today

Andy Koppe wrote: > Cygwin isn't Windows; it's a POSIX environment on top of Windows. > Taking the Regional Settings control panel into account might well > make sense, but it ought to be left to the Cygwin developers to decide > on this and implement it centrally. And it is the duty of the gettex

Re: cygwin started speaking German today

Hello Corinna, Corinna Vinschen wrote: > > After Cygwin 1.7 added working locales and defined LANG=C.UTF-8 for all > > users, > > libintl could be extended to respect the choices the user has made in the > > system control panels. > > That's the wrong approach. Before discussing the technical d

Re: cygwin started speaking German today

Bernhard Voelker wrote: > > Starting with today's update, cygwin started speaking German: > > > > $ mkdir -v x0 > > mkdir: Verzeichnis „x0“ angelegt > > $ LANG=C mkdir -v x2 > > mkdir: created directory `x2' > > $ LANG=C.UTF-8 mkdir -v x1 > > mkdir: Verzeichnis „x1“ angelegt > > > > Defau

Re: 16-bit wchar_t on Windows and Cygwin

Corinna Vinschen wrote: > isn't wwchar_t equivalent to wint_t on all > platforms? On UCS-4 platforms sizeof(wint_t) == sizeof(wchar_t) == 4 > because there's no reason to make it bigger. On UCS-2 and UTF-16 > platforms sizeof(wint_t) == 4 because it must be able to hold EOF as > well. So, why no

Re: 16-bit wchar_t on Windows and Cygwin

Hi Eric, > I was asking: > > should wwchar_t (or xwchar_t, but not xchar_t) be 2-bytes on cygwin, but > unlike the POSIX definition of wchar_t being always 1 character per > unit, the new type is explicitly documented as being multi-unit on some > platforms but with sane semantics > > or should

Re: 16-bit wchar_t on Windows and Cygwin

Hello Eric, > > Here's a new proposal: > > - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t > > on Windows platforms and to 'wchar_t' otherwise. > > - Define functions 'mbrtowwc', 'iswwalpha', 'wwcwidth', and similar. > > Their definition will be a trivial redirectio

Re: Bug in libiconv?

[resent to the cygwin list; please add bug-gnu-libiconv to your replies] Hi Corinna, Thanks for your reply > > Please CC the bug-gnu-libiconv mailing list when discussing possible > > bugs in GNU libiconv. > > Ok Thanks for giving it a try. Bu

Re: bug#7948: 16-bit wchar_t on Windows and Cygwin

Hi Paul, > > - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t > > on Windows platforms and to 'wchar_t' otherwise. > > As a minor point, would it be OK to call this type > 'xchar_t' instead? 'x' is the successor to 'w', after all, > and it can be thought of as an abbrevi

Re: 16-bit wchar_t on Windows and Cygwin

Hello Corinna, > And, please note the wording in SUSv4, for instance in > http://calimero.vinschen.de/susv4/functions/iswalpha.html Likewise in POSIX:2008, at the URL http://www.opengroup.org/onlinepubs/9699919799/functions/iswalpha.html > The wc argument is a wint_t, the value of which the ap

Re: 16-bit wchar_t on Windows and Cygwin

Hello Eric, > ... POSIX requires that 1 wchar_t corresponds to 1 character > ... > > What consequences does this have? > > > > 1) All code that uses the functions from (wide character > > classification and mapping) or wcwidth() malfunctions on strings that > > contains Unicode chara

Re: Bug in libiconv?

Hi Corinna and Chuck, Please CC the bug-gnu-libiconv mailing list when discussing possible bugs in GNU libiconv. Replying to : > the application tests to convert a UTF-8 to WCHAR_T string in four > combinations of the current locale, in t

Re: 1.7.7: Localization does not follow the language of the OS

Replying to : > I have a Dutch windows version, so > on my PC the application should automatically set its language to Dutch. > I want to release this application to users with different language > preferences, and on their PCs the application

wctob function overwrites caller-owned register

In Cygwin 1.7.2, the wctob() function clobbers the %ebx register, which belongs to the caller. The effects are random behaviour and crashes in the caller. How to reproduce: = Compile this program, consisting of 2 parts, without optimization. It works fine. ===

Re: weak symbols on Cygwin

Dave Korn wrote: >> I've got some code, written for ELF platforms, that detects whether the >> pthread library (often a separate library from libc) is linked, by doing >> >> #pragma weak pthread_cancel >> bool pthread_in_use = (pthread_cancel != NULL); > > And you really need to determine this

Re: weak symbols on Cygwin

Hi Dave, > on ELF platforms, you can leave undefined references in an executable, to > be filled in by ld.so at runtime according to what the loader finds present > once it's loaded libc. > ... > On windows ... There's no run-time process of > scanning all available symbols from all loaded libr

Re: weak symbols on Cygwin

Hi Dave, Dave Korn wrote: > >> These were all due to the fact that gcc 4.3.x on Cygwin 1.7.2 > >> accepts "#pragma weak foo", but the symbol foo then evaluates > >> to the NULL address, even if foo is defined in libc. > > > > Dave, are weak symbols something that should work on cygwin with new >

how to pass non-ASCII environment variable values to cygwin programs?

Hi, I'm trying to pass non-ASCII strings as environment variable values from one program to another. It does not work when a mingw program invokes a cygwin program, but works when the caller is a cygwin program or the callee is a mingw program. Cygwin in use is 1.5.25, on Windows XP. How to repr

simple multithread program fails on Cygwin, succeeds on Linux

Hi, The attached test program for pthread_once uses the following basic POSIX threads functions: pthread_create pthread_join pthread_mutex_init pthread_mutex_lock pthread_mutex_unlock pthread_once pthread_rwlock_init pthread_rwlock_rdlock pthread_rwlock_unlock pthread_rwlock_wr

Re: setfacl on Cygwin

Corinna Vinschen wrote: > > What error code do you want? EINVAL? EINVAL sounds right, yes. The Solaris manual page [1] also mentions it: "EINVAL ... the cmd argument is SETACL or ACE_SETACL and the ACL specified in aclbufp is not valid." > I applied a patch to CVS so this situation wi

Re: why is pthread_key_create failing?

Dear Corinna, Thank you for the rapid answer. > The pthread_key_create function checks the incoming pthread_key_t pointer > for being a valid object already and,if so, bails out with EBUSY. The POSIX specification of this function [1] mentions that some value shall be stored in *KEY but does not

why is pthread_key_create failing?

Hi, In the test program below, pthread_key_create is failing with return value EBUSY with no good reason. The explanation in http://www.mail-archive.com/cygwin%40cygwin.com/msg49835.html does not apply since I'm not calling pthread_key_create on an existing key's address, but a destroyed key's add

Re: compilation errors

Hi, [EMAIL PROTECTED] writes: > While compiling gettext (0.11.5) under windows 2000 with cygwin > (1.3.19.1), gcc (version 3.2 20020927), and GNU make (version 3.79.1), I > ran into the following error messages: > > = > gcc -g -O2 -o .libs/msgcmp.exe msgcmp.o > .libs/li