This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/14185] fnmatch() fails when '*' wildcard is applied on the file name containing multi-byte character(s)
- From: "law at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 31 May 2012 02:49:09 +0000
- Subject: [Bug libc/14185] fnmatch() fails when '*' wildcard is applied on the file name containing multi-byte character(s)
- Auto-submitted: auto-generated
- References: <bug-14185-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14185
law at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
--- Comment #2 from law at redhat dot com 2012-05-31 02:49:09 UTC ---
AFAICT there are no defined errors from fnmatch. It's defined as returning 0
for a match, FNM_NOMATCH for no match and another non-zero value for an error.
However, no specific error codes are defined.
But what doesn't make sense about the current implementation is if pattern is
something like *.csv and the string is <invalid>.csv, then we return an error.
To me that seems plainly wrong as we can get a positive match regardless of the
invalid character in the string.
As you note, it makes rm -f * fail as will "find" and a variety of other tools
which rely upon fnmatch. This actually came to our attention because "find"
was missing an obvious match because of an invalid character in a filename.
It's worth noting that gnulib's fnmatch has been fixed to address this problem.
Yes, there's an additional issue with handling out of memory conditions with
large strings. We don't have a fix for that and I think it should be tracked
as a separate and distinct issue.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.