https://pubs.opengroup.org/onlinepubs/9699919799/functions/fnmatch.html talks about matching characters.   I'm not clear on whether "*" is required to match a byte which is part of a sequence which does not encode a valid character in the current encoding, or for that matter whether it is required not to.

ISTR that gnulib works the way it does because the relevant byte sequences don't encode a "character" in the selected encoding.  

Eric, (I'm assigning the bug to you to check this) is this consistent with your understanding?

Also, it seems that on my system, find does not use gnulib's fnmatch (as there is no fnmatch.o file lying around after build), and the system fnmatch works fine, i.e. the test program outputs "Match!" in all the locales I tested (en_US.UTF-8, de_DE.UTF-8, C).


$ cat /home/lars/tmp/fnmatch/src/testfnm.c
#include <config.h>
#include <stdio.h>
#include "fnmatch.h"

int main(void) {
    char *str = "Die_Toten_Hosen_-_Mein_groe\337ter_Feind.ogg";
    char pat = "*Feind";
    int r = fnmatch(pat, str, 0);

    printf("STRING: %s\n", str);
    printf("PATTERN: %s\n", pat);
    if (r == 0)
        printf("Match!\n");
    else if (r == FNM_NOMATCH)
        printf("No match!\n");
    else
        printf("Error %d", r);
    return 0;
}

Yes, this looks like a limitation in the gnulib (current as of just now) gnmatch implementation.  Still occurs in find-4.5.8.

/tmp/testcase$ LC_ALL=zh_TW.UTF-8 /home/james/source/GNU/findutils/git/gnu/compile/64/find/find oo -name '*'|nl
     1 oo
     2 oo/Thumbs.db
/tmp/testcase$ LC_ALL=zh_TW.UTF-8 /home/james/source/GNU/findutils/git/gnu/compile/64/find/find oo |nl
     1 oo
     2 oo/��+R+�+ЪԦm�W�d++.pdf
     3 oo/��+RRGB.jpg
     4 oo/��+R����-���F�|+��ʽO+@�p.ai
     5 oo/�]�p�z�+.pdf
     6 oo/Thumbs.db
     7 oo/��+R+�+�_A2.pdf
     8 oo/��+R+�+��U��++.pdf

(reminder: if you don't have that charset installed, you will not be able to reproduce the problem)

Don't you see the attached test case files?

Here's even a new test case not in a file:
set -eu
n=/tmp/oo
mkdir -p $n; cd $n
#recode qp <<! SORRY MAN can't figure out recode syntax
perl -MMIME::QuotedPrint -nwle 'print decode_qp($_);' <<!|xargs touch
Thumbs.db
=A6]=A1p=A6z=AE+.pdf
=A6=FE+R+=F0+=D0_A2.pdf
=A6=FE+R+=F0+=D0=AA=D4=A6m=A6W=A2d++.pdf
=A6=FE+R+=F0+=D0=F1U=A9=B3++.pdf
=A6=FE+RRGB.jpg
=A6=FE+R=A1=FD=A6=A4-=AA=B5=BCF=A6|+=B6=A6=CA=BDO+@=A9p.ai
!
set -x
ls|nl
LC_ALL=zh_TW.UTF-8 find -name \*|nl
LC_ALL=C find -name \*|nl
find --version|head -n 1

All that's lacking here is a short shell script to reproduce the problem on a recent findutils version (for example 4.5.5).

This might be a limitation of the fnmatch() implementation, but even if so it may well be possible to do better here.  The first thing we'll need is a reproducible test case (I can probably convert that into a regression test case).

Could you provide a short shell script which generates a file with a suitable name and demonstrates the problem?