Re: symbolic link curiousity in 3.6.0

2025-04-09 Thread Corinna Vinschen
Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Regarding what acl_extended_file() does, there is the man page by > > > Andreas Grünbacher: > > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.htm

Re: symbolic link curiousity in 3.6.0

2025-04-05 Thread Corinna Vinschen
Hi Bruno, thanks for your quick reply! On Mar 28 15:30, Bruno Haible via Cygwin wrote: > [CCing bug-gnulib] > > Corinna Vinschen wrote in > <https://sourceware.org/pipermail/cygwin/2025-March/257751.html>: > > I found the problem, it's in a gnulib header. See be

Re: symbolic link curiousity in 3.6.0

2025-03-31 Thread Corinna Vinschen
On Mar 31 12:12, Paul Eggert via Cygwin wrote: > On 3/31/25 11:27, Pádraig Brady wrote: > > The file could be deleted at any time. > > We're just suppressing errors in the edge case it's deleted > > More generally, though, the file could be renamed and another put in its > place, which means that

Re: symbolic link curiousity in 3.6.0

2025-03-30 Thread Corinna Vinschen
Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Regarding what acl_extended_file() does, there is the man page by > > > Andreas Grünbacher: > > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.htm

Re: symbolic link curiousity in 3.6.0

2025-03-30 Thread Corinna Vinschen
Hi Paul, thanks for the patch. On Mar 29 10:31, Paul Eggert via Cygwin wrote: > On 3/29/25 04:30, Corinna Vinschen wrote: > > What it should do if only the POSIX.1e draft 17 functions are available > > is something along these lines: > > Yes, that sounds like a bet

Re: symbolic link curiousity in 3.6.0

2025-03-29 Thread Corinna Vinschen
On Mar 29 12:58, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > Btw., while I was testing test-file-has-acl.sh, I found two more bugs, > > one in test-file-has-acl.sh, and one (a problem of account handling in > > Windows) in Cygwin's setfacl(1). Togethe

Re: symbolic link curiousity in 3.6.0

2025-03-29 Thread Corinna Vinschen
On Mar 29 13:12, Corinna Vinschen via Cygwin wrote: > On Mar 29 12:43, Bruno Haible via Cygwin wrote: > > OK, and what does this mean for the *files* created in such a directory? > > Just for clarity, permissions in Windows are *always* defined by an ACL. > There's no such

Re: symbolic link curiousity in 3.6.0

2025-03-29 Thread Corinna Vinschen
On Mar 29 12:43, Bruno Haible via Cygwin wrote: > Hi Corinna, > > > c) The expectations of test-file-has-acl.sh are wrong. > > The Cygwin-specific part of that unit test has minimal expectations: > > # Set an ACL for a group. > if setfacl -m group:0:1 tmpfile0; then > >

Re: symbolic link curiousity in 3.6.0

2025-03-29 Thread Corinna Vinschen
Hi Pádraig, thanks for your reply! On Mar 28 20:30, Pádraig Brady via Cygwin wrote: > On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote: > > [CCing bug-gnulib] > > > > Corinna Vinschen wrote in > > <https://sourceware.org/pipermail

Re: disabling the CI on Cygwin

2025-02-03 Thread Corinna Vinschen
Hi Bruno, On Jan 30 00:43, Bruno Haible wrote: > Hi Corinna, > > Corinna Vinschen wrote: > > > I keep the Cygwin (32-bit) CI, since that is running a fixed release > > > (3.3.6) — > > > no risk of regressions caused by Cygwin. > > > > We released

Re: disabling the CI on Cygwin

2025-01-29 Thread Corinna Vinschen
Hi Bruno, On Dec 25 07:42, Bruno Haible wrote: > The newest Cygwin release (3.5.5) has three major regressions: > - bash hangs [1] > - access() behaviour changed [2] > - raise() produces random behaviour [3] > > The first one has the potential to hang the CI for 6 hours; the second and > th

Re: random(3) in OpenBSD

2023-11-14 Thread Corinna Vinschen
Hi Bruno, On Nov 14 19:33, Bruno Haible wrote: > [CCing bug-gnulib] > > Hi Corinna, > > > Looking into all the BSD variants of random(), I found that OpenBSD > > defaults the random() function to return non-deterministic output. It > > works like this: > > > > - A global var random_determinis

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-17 Thread Corinna Vinschen
On Feb 17 09:30, Reuben Thomas wrote: > On Sat, 11 Feb 2023 at 12:40, Corinna Vinschen wrote: > > > On Feb 11 12:29, Reuben Thomas wrote: > > > On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen > > wrote: > > > > > > > > > > > If

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-11 Thread Corinna Vinschen
On Feb 11 12:29, Reuben Thomas wrote: > On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen wrote: > > > > > If you're sure that the native recode.dll has been built, is it possible > > that it's just not found, because it's not in Windows' DLL search path

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-11 Thread Corinna Vinschen
On Feb 11 11:36, Reuben Thomas wrote: > On Fri, 10 Feb 2023 at 14:21, Bruno Haible wrote: > > > It complains about the symbols defined in libiconv. This means, you need > > to invoke the Gnulib module 'iconv' and add $(LIBICONV) or $(LTLIBICONV) > > to the LDFLAGS. > > > > Bruno to the rescue ag

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-07 Thread Corinna Vinschen
Hi Reuben, On Feb 7 14:22, Corinna Vinschen wrote: > On Feb 6 20:50, Reuben Thomas wrote: > > On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote: > > > > > 1. 'recode' is updated to a current gnulib and publish a corresponding > > > tarball.

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-07 Thread Corinna Vinschen
On Feb 6 20:50, Reuben Thomas wrote: > On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote: > > > 1. 'recode' is updated to a current gnulib and publish a corresponding > > tarball. (Hi Reuben :) ) > > > > I've updated gnulib in recode git; I'd be grateful if I could have a report > that it'

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-06 Thread Corinna Vinschen
On Feb 6 21:38, Bruno Haible wrote: > Corinna Vinschen wrote: > > I just ran the setlocale_null-mt-* tests with gnulib from git master > > under Cygwin with my newlib patch, and the tests succeeded. I checked > > that configure is doing the right thing and config

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-06 Thread Corinna Vinschen
On Feb 6 18:37, Bruno Haible wrote: > Corinna Vinschen wrote: > > This patch will be in the next Cygwin release 3.4.6. > > Thanks! > > > I'm just a bit fuzzy what patches will be required for gnulib now... > > With this patch, the setlocale_null lock sho

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-06 Thread Corinna Vinschen
Hi Bruno, On Feb 5 22:22, Corinna Vinschen wrote: > On Feb 5 21:41, Bruno Haible wrote: > > Another option — since we are talking about a single symbol and a single > > platform — would be if the locking for setlocale_null were not necessary > > on Cygwin in the first pla

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-05 Thread Corinna Vinschen
On Feb 5 21:41, Bruno Haible wrote: > Hi Corinna, > > Thanks for the heads-up and patch. > > > Note that dllimport/dllexport decorations are not at all required on > > Cygwin for quite some time. > > Is this true in all circumstances? I thought that when --disable-auto-import > is in use AND th

[PATCH] Do not decorate symbols as dllexport on Cygwin

2023-02-05 Thread Corinna Vinschen
Note that dllimport/dllexport decorations are not at all required on Cygwin for quite some time. Worse, this breaks building DLLs and DLL import libs using libtool. On Cygwin --export-all-symbols is default. However, if just a single symbol is decorated with dllexport, ld switches to exporting o

Re: [Grep-devel] handling of non-BMP characters

2018-12-19 Thread Corinna Vinschen
On Dec 19 15:41, Corinna Vinschen wrote: > On Dec 19 08:51, Bruno Haible wrote: > > Corinna Vinschen wrote in > > <https://lists.gnu.org/archive/html/grep-devel/2018-12/msg00039.html>: > > > it would be > > > pretty nice if that code could get reverted ba

Re: [Grep-devel] handling of non-BMP characters

2018-12-19 Thread Corinna Vinschen
On Dec 19 08:51, Bruno Haible wrote: > Corinna Vinschen wrote in > <https://lists.gnu.org/archive/html/grep-devel/2018-12/msg00039.html>: > > it would be > > pretty nice if that code could get reverted back in to support > > non-BMP charsets even on Cygwin. > >

Re: [PATCH] root-uid: new module

2012-06-27 Thread Corinna Vinschen
yet. This might be a nice project for somebody who wants to contribute to Cygwin, since its implementation is mostly independent from the already existing functionality. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat

Re: 16-bit wchar_t on Windows and Cygwin

2011-02-03 Thread Corinna Vinschen
'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 not just use the wint_t type for the time being? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat

Re: 16-bit wchar_t on Windows and Cygwin

2011-02-02 Thread Corinna Vinschen
y use 'x' instead of 'ww' when > replacing existing 'w' in POSIX APIs. May I suggest a compromise? What about "xwchar_t"? It avoids the potential typo by accidentally dropping the second w. It still contains "wchar" which implies that it's a *wide* char type. And the x could be read as "extended". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat

Re: Bug in libiconv?

2011-02-02 Thread Corinna Vinschen
IN32__ manually, deserves the result. > > But such a user will then write a mail to a mailing list, and it will take > time for me (or someone else) to investigate and answer it. By writing > #if (defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__ > I avoid this potential problem. Ok. However, the other variation #if defined _WIN32 || defined __WIN32__ || defined __CYGWIN__ should be only used in very rare circumstances. Usually it just means that some unnecessary Windowism is used on Cygwin, and that there's probably a POSIXy equivalent. If not, kick us here on the list and we can discuss it. > Thanks again for your reply and for the hint to the bug in libiconv's code. You're welcome and thanks for this fruitful discussion. I'm glad if we can find a well-working compromise for some of the problems, especially in the unfortunate UTF-16 case. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat