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 manual/14029] New: glibc manual wrongly claims fnmatch cannot fail


http://sourceware.org/bugzilla/show_bug.cgi?id=14029

             Bug #: 14029
           Summary: glibc manual wrongly claims fnmatch cannot fail
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: manual
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
                CC: mtk.manpages@gmail.com, roland@gnu.org
    Classification: Unclassified


Per http://www.gnu.org/software/libc/manual/html_node/Wildcard-Matching.html

"In the GNU C Library, fnmatch cannot experience an âerrorââit always returns
an answer for whether the match succeeds. However, other implementations of
fnmatch might sometimes report âerrorsâ. They would do so by returning nonzero
values that are not equal to FNM_NOMATCH."

In fnmatch.c:

 433           wstring_malloc = wstring
 434             = (wchar_t *) malloc ((n + 1) * sizeof (wchar_t));
 435           if (wstring == NULL)
 436             {
 437               free (wpattern_malloc);
 438               return -2;
 439             }

Note that glibc's fnmatch requires memory to allocate a typically-4x-expanded
copy of both the pattern and string (since they're converted to wchar_t
strings). This means on a 32-bit system, fnmatch("*", long_string, 0) will
always fail with -2 for strings at least 600 MB in length, when of course it
should obviously succeed.

I'm filing this as a bug against the manual since I suspect there is not the
will to fix it in the code, and the manual should probably just be fixed to
state that fnmatch can and will fail. However, I actually noticed it while
designing a new bounded-space algorithm for musl's fnmatch, which glibc would
of course be welcome to adopt in the future if there is interest in fixing the
code side (but I have my doubts that the algorithm could support glibc's
FNM_EXTMATCH option).

-- 
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]