This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/14185] fnmatch() fails when '*' wildcard is applied on the file name containing multi-byte character(s)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]