[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140721143323.GP17402@brightrain.aerifal.cx>
Date: Mon, 21 Jul 2014 10:33:23 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] implement glibc's glob_pattern_p
On Thu, Jul 17, 2014 at 01:12:55PM +0400, Glauber Costa wrote:
> Currently, glob is implemented but glob_pattern_p is not. This function
> can trivially be implemented with existing glob machinery, since all it
> does is to tell whether or not the string contains special symbols. This
> is basically the same logic as is_literal, but with inverted return value.
>
> The value of the "quote" parameter should also be inverted, since the man
> page states that when the quote parameter is *non*-zero, then backslashes
> are ignored. is_literal ignores them when useesc is *zero*.
Upon reviewing this patch, I'm not sure if it's correct. It wrote this
code (glob.c) roughly 10 years ago and barely touched it since, but
from what I can tell, the existing is_literal looks like a premature
optimization to avoid calling fnmatch when it's not necessary than an
accurate predicate. In other words, it's designed to reliably return 0
if the string is a glob, but there are also cases where it returns 0
when the string is not a "glob pattern" but not purely a literal
either (e.g. anything containing backslash when useesc is nonzero,
since such strings cannot be processed with strcmp and need fnmatch).
My leaning would be to remove this "optimization" from glob.c entirely
(it shouldn't be needed if fnmatch is efficient) and move the code to
a separate file for glob_pattern_p, but then we need to make sure it
gets things right with no false positives or false negatives.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
