Re: fnmatch improvements

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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