i don't see how `[[.collating-element.]]' really work. I tried for es_ES [[.ll.]] or [[.l-l.]] or [[.<l-l>.]] to match the string `ll' and it doesn't work. locale was set with setlocale(return was not null), and with export LC_COLLATE=es_ES so far i see 2 bugs in posix/fnmatch_loop.c in line 590, should be: if (n[c1] != wextra[1 + idx + c1]), (the + idx, is missing) line 808 is very strange: idx = (idx + 3) & ~4; it should probably be `& ~3', thanks
The "ll" collating-element is not defined in the es_ES locale, only in the es_US locale.
(In reply to Andreas Schwab from comment #1) > The "ll" collating-element is not defined in the es_ES locale, only in the > es_US locale. what am i missing? $: export LC_COLLATE=es_US $: sort <<\eof l lla lb eof =>l =>lb =>lla $: touch ll.c $: ls [[.l-l.]].c => ls: cannot access [[.l-l.]].c: No such file or directory And besides, what about the 2 bugs i've shown in the source code? thanks
I didn't say anything about the correctness of collating element matching.
also, n should be incremted accordingly, (c1, but 1 is always incremented at the bottom of the loop, so it should be c1 -1). For future reference, these 3 or so (there are a multiple of those...) bug-fixes would SOLVES the problems completely.
one more thing, n should be cast to unsigned char before it is compared to any 'extra' slot..(the not wide char version...)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 65f7767a914144ae303f7b9ae81865061793dcb9 (commit) from 3f635fb43389b54f682fc9ed2acc0b2aaf4a923d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=65f7767a914144ae303f7b9ae81865061793dcb9 commit 65f7767a914144ae303f7b9ae81865061793dcb9 Author: Andreas Schwab <schwab@suse.de> Date: Tue Sep 16 11:17:04 2014 +0200 Fix handling of collating elements in fnmatch (bug 17396, bug 16976) This fixes the same bug in fnmatch that was fixed by commit 7e2f0d2d77 for regexp matching. As a side effect it also removes the use of an unbound VLA. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 19 ++ include/wchar.h | 2 + posix/Makefile | 4 +- posix/fnmatch.c | 6 +- posix/fnmatch_loop.c | 228 ++++++++------------- elf/tst-absolute-sym.c => posix/tst-fnmatch4.c | 25 ++- nptl/tst-mtx-recursive.c => posix/tst-fnmatch5.c | 37 ++-- sysdeps/i386/i686/multiarch/wmemcmp.c | 3 +- sysdeps/s390/wmemcmp.c | 7 +- sysdeps/x86_64/multiarch/wmemcmp.c | 3 +- wcsmbs/wmemcmp.c | 9 +- 11 files changed, 163 insertions(+), 180 deletions(-) copy elf/tst-absolute-sym.c => posix/tst-fnmatch4.c (67%) copy nptl/tst-mtx-recursive.c => posix/tst-fnmatch5.c (62%)
Fixed in 2.30