Re: fnmatch improvements
On Fri, Jul 28, 2023 at 5:12 AM Corinna Vinschen wrote: I'm puzzled because I'm an idiot. > That's one thing you certainly are not. Bill -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 test failures) > > # TOTAL: 218 > # PASS: 178 > # SKIP: 40 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. > > > cd .. > > 2. cd testdir-fnmatch-gnu > > ./configure > > grep REPLACE_FNMATCH config.status > > (Expected: REPLACE_FNMATCH is 1, because of FNM_EXTMATCH) > > $ grep REPLACE_FNMATCH config.status > S["REPLACE_FNMATCH"]="1" > > > make > > make check > > (Expected: No test failures) > > # TOTAL: 218 > # PASS: 178 > # SKIP: 40 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > Same SKIP of test-fnmatch-5.sh. > > Does that look ok? Yes, that's all OK and as expected. I'll commit the fnmatch.m4 patch today. When the user asks for an fnmatch() with FNM_EXTMATCH support, they will get the Gnulib fnmatch(), as it supports these GNU extensions. I'll think about how to make [=X=] and [.X.] work in this case too... Thank you for your constructive cooperation! Bruno -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 28 12:56, Bruno Haible via Cygwin wrote: > It's sometimes hard to make incremental changes to generated files of the > GNU Build System plus Gnulib. I've therefore recreated a new tarball for you, > at https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz . > > The expected result is: > 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 test failures) # TOTAL: 218 # PASS: 178 # SKIP: 40 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. > cd .. > 2. cd testdir-fnmatch-gnu > ./configure > grep REPLACE_FNMATCH config.status > (Expected: REPLACE_FNMATCH is 1, because of FNM_EXTMATCH) $ grep REPLACE_FNMATCH config.status S["REPLACE_FNMATCH"]="1" > make > make check > (Expected: No test failures) # TOTAL: 218 # PASS: 178 # SKIP: 40 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Same SKIP of test-fnmatch-5.sh. Does that look ok? Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 regenerate the testdir from scratch. Bruno -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 28 12:56, Bruno Haible via Cygwin wrote: > 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 > > checking for working POSIX fnmatch... yes > > > > I'm quite puzzled. > > It's sometimes hard to make incremental changes to generated files of the > GNU Build System plus Gnulib. I've therefore recreated a new tarball for you, > at https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz . Thanks, I'll use that for testing later today. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 28 10:53, Corinna Vinschen via Cygwin wrote: > On Jul 27 23:40, Bruno Haible via Cygwin wrote: > > Corinna Vinschen wrote: > > > S["REPLACE_FNMATCH"]="1" > > > > > > Looks like the reason is that we don't have a uchar.h file? Seems > > > like this is of interest for AIX, but why should this be of > > > interest for fnmatch on other systems? > > > > Ah, that's because I made the assumption that if wchar_t is only 16-bits > > wide, fnmatch() can't be correct. Which is true for AIX (and on this > > platform, I prefer not to test the available locales). But not true > > with your implementation any more. > > > > What are the test suite results if you do > > > > - Replace S["REPLACE_FNMATCH"]="1" with S["REPLACE_FNMATCH"]="0" > > in config.status, > > - make clean > > - ./config.status > > - make > > The build fails here. The reason is that the GNU extension FNM_EXTMATCH > is not supported by the FreeBSD code base of fnmatch, so it's not > defined in our fnmatch.h system header. Gnulib still tries to build > fnmatch_loop.c which uses FNM_EXTMATCH, but apparently it now relies on > using the system header? > [...] > 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 > checking for working POSIX fnmatch... yes > > I'm quite puzzled. I'm puzzled because I'm an idiot. I forgot autoreconf. After that and another configure run, REPLACE_FNMATCH is correctly set to 0 *and* the build runs fine. I'll do the rest of the test later today. Sorry, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 > checking for working POSIX fnmatch... yes > > I'm quite puzzled. It's sometimes hard to make incremental changes to generated files of the GNU Build System plus Gnulib. I've therefore recreated a new tarball for you, at https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz . The expected result is: 1. cd testdir-fnmatch-posix ./configure grep REPLACE_FNMATCH config.status (Expected: REPLACE_FNMATCH is 0) make make check (Expected: No test failures) cd .. 2. cd testdir-fnmatch-gnu ./configure grep REPLACE_FNMATCH config.status (Expected: REPLACE_FNMATCH is 1, because of FNM_EXTMATCH) make make check (Expected: No test failures) cd .. Bruno -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 28 11:00, Corinna Vinschen via Cygwin wrote: > If we do that, I think the functions > should actually be renamed accordingly and the globbing code should use > uchar32_t rather than wint_t. s/uchar32_t/char32_t/ -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 27 16:17, Brian Inglis via Cygwin wrote: > On 2023-07-27 15:22, Bruno Haible wrote: > > 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://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=416 > > > > > > $ find /usr/include/ -name uchar.h > > > /usr/include/unicode/uchar.h > > > > > > $ cygcheck -f /usr/include/unicode/uchar.h > > > libicu-devel-72.1-1 > > > > This file, from ICU4C, is something completely different > > than > > ISO C's . > > This would then be a *newlib* AT sourceware DOT org addition so we could use > FreeBSD's: We can use FreeBSDs version as role model, but we can't use the code verbatim, given FreeBSD assumes sizeof(wchar_t) == 4. Since that's a Cygwin-only issue (2 byte wchar_t, that is), I guess we should merge the code into the Cygwin code base, rather than newlib. For mbrtoc32/c32rtomb, we can use the wirtomb/mbrtowi function I introduced for the globbing code. If we do that, I think the functions should actually be renamed accordingly and the globbing code should use uchar32_t rather than wint_t. Also, it might be helpful to add the mbrtoc8/c8rtomb extensions at one point, which are missing in FreeBSD. Either way, I'd be grateful for patches in this area. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 27 23:40, Bruno Haible via Cygwin wrote: > 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 configure tests needed on the gnulib side). > > > > > grep fnmatch log1 > > > > checking for fnmatch.h... yes > > checking for fnmatch... yes > > checking for working POSIX fnmatch... yes > > > > I also extraced the fnmatch configure testcase and ran it manually. > > It returns 0 now. But: > > > > > > grep REPLACE_FNMATCH config.status > > > > S["REPLACE_FNMATCH"]="1" > > > > Looks like the reason is that we don't have a uchar.h file? Seems > > like this is of interest for AIX, but why should this be of > > interest for fnmatch on other systems? > > Ah, that's because I made the assumption that if wchar_t is only 16-bits > wide, fnmatch() can't be correct. Which is true for AIX (and on this > platform, I prefer not to test the available locales). But not true > with your implementation any more. > > What are the test suite results if you do > > - Replace S["REPLACE_FNMATCH"]="1" with S["REPLACE_FNMATCH"]="0" > in config.status, > - make clean > - ./config.status > - make The build fails here. The reason is that the GNU extension FNM_EXTMATCH is not supported by the FreeBSD code base of fnmatch, so it's not defined in our fnmatch.h system header. Gnulib still tries to build fnmatch_loop.c which uses FNM_EXTMATCH, but apparently it now relies on using the system header? > - make check > > Then the tests will be run against Cygwin's fnmatch() function. > If all tests pass, I will add the following patch to gnulib. 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 checking for working POSIX fnmatch... yes I'm quite puzzled. Corinna > > diff --git a/m4/fnmatch.m4 b/m4/fnmatch.m4 > index 2e1442eff7..e99737a476 100644 > --- a/m4/fnmatch.m4 > +++ b/m4/fnmatch.m4 > @@ -1,4 +1,4 @@ > -# Check for fnmatch - serial 18 -*- coding: utf-8 -*- > +# Check for fnmatch - serial 19 -*- coding: utf-8 -*- > > # Copyright (C) 2000-2007, 2009-2023 Free Software Foundation, Inc. > # This file is free software; the Free Software Foundation > @@ -14,7 +14,7 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] >m4_divert_text([DEFAULTS], [gl_fnmatch_required=POSIX]) > >AC_REQUIRE([gl_FNMATCH_H]) > - AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles > + AC_REQUIRE([AC_CANONICAL_HOST]) >gl_fnmatch_required_lowercase=` > echo $gl_fnmatch_required | LC_ALL=C tr '[[A-Z]]' '[[a-z]]' >` > @@ -164,7 +164,17 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] > dnl This is due to wchar_t being only 16 bits wide. > AC_REQUIRE([gl_UCHAR_H]) > if test $SMALL_WCHAR_T = 1; then > - REPLACE_FNMATCH=1 > + case "$host_os" in > +cygwin*) > + dnl On Cygwin < 3.5.0, the above $gl_fnmatch_result came out as > 'no', > + dnl On Cygwin >= 3.5.0, fnmatch supports all Unicode characters, > + dnl despite wchar_t being only 16 bits wide (because internally it > + dnl works on wint_t values). > + ;; > +*) > + REPLACE_FNMATCH=1 > + ;; > + esac > fi >fi >if test $HAVE_FNMATCH = 0 || test $REPLACE_FNMATCH = 1; then > > > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On 2023-07-27 15:22, Bruno Haible wrote: 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://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=416 $ find /usr/include/ -name uchar.h /usr/include/unicode/uchar.h $ cygcheck -f /usr/include/unicode/uchar.h libicu-devel-72.1-1 This file, from ICU4C, is something completely different than ISO C's . This would then be a *newlib* AT sourceware DOT org addition so we could use FreeBSD's: https://cgit.freebsd.org/src/blame/include/uchar.h?id=9f9d157d82e2332b74d9c45b596748e3e4691f2d plus consideration of: gnulib: https://git.savannah.gnu.org/gitweb/?p=gnulib.git=search=HEAD=commit=uchar.h and C2023 CD2: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf there are only symbol formatting changes in N3148 comments and N3149 is a zip with a password protected PDF so likely FDIS! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 configure tests needed on the gnulib side). > > > grep fnmatch log1 > > checking for fnmatch.h... yes > checking for fnmatch... yes > checking for working POSIX fnmatch... yes > > I also extraced the fnmatch configure testcase and ran it manually. > It returns 0 now. But: > > > > grep REPLACE_FNMATCH config.status > > S["REPLACE_FNMATCH"]="1" > > Looks like the reason is that we don't have a uchar.h file? Seems > like this is of interest for AIX, but why should this be of > interest for fnmatch on other systems? Ah, that's because I made the assumption that if wchar_t is only 16-bits wide, fnmatch() can't be correct. Which is true for AIX (and on this platform, I prefer not to test the available locales). But not true with your implementation any more. What are the test suite results if you do - Replace S["REPLACE_FNMATCH"]="1" with S["REPLACE_FNMATCH"]="0" in config.status, - make clean - ./config.status - make - make check Then the tests will be run against Cygwin's fnmatch() function. If all tests pass, I will add the following patch to gnulib. diff --git a/m4/fnmatch.m4 b/m4/fnmatch.m4 index 2e1442eff7..e99737a476 100644 --- a/m4/fnmatch.m4 +++ b/m4/fnmatch.m4 @@ -1,4 +1,4 @@ -# Check for fnmatch - serial 18 -*- coding: utf-8 -*- +# Check for fnmatch - serial 19 -*- coding: utf-8 -*- # Copyright (C) 2000-2007, 2009-2023 Free Software Foundation, Inc. # This file is free software; the Free Software Foundation @@ -14,7 +14,7 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] m4_divert_text([DEFAULTS], [gl_fnmatch_required=POSIX]) AC_REQUIRE([gl_FNMATCH_H]) - AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles + AC_REQUIRE([AC_CANONICAL_HOST]) gl_fnmatch_required_lowercase=` echo $gl_fnmatch_required | LC_ALL=C tr '[[A-Z]]' '[[a-z]]' ` @@ -164,7 +164,17 @@ AC_DEFUN([gl_FUNC_FNMATCH_POSIX] dnl This is due to wchar_t being only 16 bits wide. AC_REQUIRE([gl_UCHAR_H]) if test $SMALL_WCHAR_T = 1; then - REPLACE_FNMATCH=1 + case "$host_os" in +cygwin*) + dnl On Cygwin < 3.5.0, the above $gl_fnmatch_result came out as 'no', + dnl On Cygwin >= 3.5.0, fnmatch supports all Unicode characters, + dnl despite wchar_t being only 16 bits wide (because internally it + dnl works on wint_t values). + ;; +*) + REPLACE_FNMATCH=1 + ;; + esac fi fi if test $HAVE_FNMATCH = 0 || test $REPLACE_FNMATCH = 1; then -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=416 > > $ find /usr/include/ -name uchar.h > /usr/include/unicode/uchar.h > > $ cygcheck -f /usr/include/unicode/uchar.h > libicu-devel-72.1-1 This file, from ICU4C, is something completely different than ISO C's . Bruno -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On 2023-07-27 13:05, Corinna Vinschen via Cygwin wrote: On Jul 27 20:24, Corinna Vinschen via Cygwin wrote: On Jul 27 12:15, Bruno Haible via Cygwin wrote: I'm looking into that. First thing, your testsuite uncovered a bug in the latest fnmatch in the C locale. Comparing pointers instead of comparing characters was never a good idea for pattern matching... When I'm done I hope that our 3.5 fnmatch won't be overridden by the gnulib version :} I can't easily install a Cygwin 3.5.0 snapshot. If one of you would like to help, here's how to: 1. Create an environment for working with a Cygwin 3.5.0 snapshot (from March 2023 or newer). 2. wget https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz 3. tar xfz testdir-fnmatch.tar.gz 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: grep fnmatch log1 checking for fnmatch.h... yes checking for fnmatch... yes checking for working POSIX fnmatch... yes I also extraced the fnmatch configure testcase and ran it manually. It returns 0 now. But: grep REPLACE_FNMATCH config.status S["REPLACE_FNMATCH"]="1" Looks like the reason is that we don't have a uchar.h file? Seems like this is of interest for AIX, but why should this be of interest for fnmatch on other systems? It was added in C99 TR19769, integrated in C/++11, 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://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=416 $ find /usr/include/ -name uchar.h /usr/include/unicode/uchar.h $ cygcheck -f /usr/include/unicode/uchar.h libicu-devel-72.1-1 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
On Jul 27 20:24, Corinna Vinschen via Cygwin wrote: > On Jul 27 12:15, Bruno Haible via Cygwin wrote: > I'm looking into that. First thing, your testsuite uncovered a bug in > the latest fnmatch in the C locale. Comparing pointers instead of > comparing characters was never a good idea for pattern matching... > > When I'm done I hope that our 3.5 fnmatch won't be overridden by the > gnulib version :} > > > I can't easily install a Cygwin 3.5.0 snapshot. If one of you would like to > > help, here's how to: > > 1. Create an environment for working with a Cygwin 3.5.0 snapshot (from > > March 2023 or newer). > > 2. wget https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz > > 3. tar xfz testdir-fnmatch.tar.gz > > 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: > > grep fnmatch log1 checking for fnmatch.h... yes checking for fnmatch... yes checking for working POSIX fnmatch... yes I also extraced the fnmatch configure testcase and ran it manually. It returns 0 now. But: > > grep REPLACE_FNMATCH config.status S["REPLACE_FNMATCH"]="1" Looks like the reason is that we don't have a uchar.h file? Seems like this is of interest for AIX, but why should this be of interest for fnmatch on other systems? Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: fnmatch improvements
Hi Bruno,
On Jul 27 12:15, Bruno Haible via Cygwin wrote:
> 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 implementation also implements GNU extensions, as documented in
> https://www.gnu.org/software/libc/manual/html_node/Wildcard-Matching.html
>
> Now, I see that in the Cygwin master branch the fnmatch implementation has
> been improved, supposedly handling non-BMP characters and character classes
> as well.
The major changes are using 32 bit unicode values internally and
implementing collating symbols and equivalence class expressions.
> Therefore I would find it interesting to know whether the Cygwin 3.5.0
> fnmatch()
> now still gets overridden by the gnulib one and, if no, whether it passes the
> gnulib test suite.
I'm looking into that. First thing, your testsuite uncovered a bug in
the latest fnmatch in the C locale. Comparing pointers instead of
comparing characters was never a good idea for pattern matching...
When I'm done I hope that our 3.5 fnmatch won't be overridden by the
gnulib version :}
> I can't easily install a Cygwin 3.5.0 snapshot. If one of you would like to
> help, here's how to:
> 1. Create an environment for working with a Cygwin 3.5.0 snapshot (from
> March 2023 or newer).
> 2. wget https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz
> 3. tar xfz testdir-fnmatch.tar.gz
> 4. cd testdir-fnmatch-posix
> ./configure 2>&1 | tee log1
> make
> make check
> grep fnmatch log1
> grep REPLACE_FNMATCH config.status
> cd ..
> 5. cd testdir-fnmatch-gnu
> ./configure 2>&1 | tee log1
> make
> make check
> grep fnmatch log1
> grep REPLACE_FNMATCH config.status
> cd ..
> and provide the build and grep results.
>
> Thanks!
>
> Bruno
No worries, thanks for the testcases, I think I have some result
tomorrow.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 implementation also implements GNU extensions, as documented in
https://www.gnu.org/software/libc/manual/html_node/Wildcard-Matching.html
Now, I see that in the Cygwin master branch the fnmatch implementation has
been improved, supposedly handling non-BMP characters and character classes
as well.
Therefore I would find it interesting to know whether the Cygwin 3.5.0 fnmatch()
now still gets overridden by the gnulib one and, if no, whether it passes the
gnulib test suite.
I can't easily install a Cygwin 3.5.0 snapshot. If one of you would like to
help, here's how to:
1. Create an environment for working with a Cygwin 3.5.0 snapshot (from
March 2023 or newer).
2. wget https://haible.de/bruno/gnu/testdir-fnmatch.tar.gz
3. tar xfz testdir-fnmatch.tar.gz
4. cd testdir-fnmatch-posix
./configure 2>&1 | tee log1
make
make check
grep fnmatch log1
grep REPLACE_FNMATCH config.status
cd ..
5. cd testdir-fnmatch-gnu
./configure 2>&1 | tee log1
make
make check
grep fnmatch log1
grep REPLACE_FNMATCH config.status
cd ..
and provide the build and grep results.
Thanks!
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
