latest glibc glob code broken

[Paul D. Smith]

Someone reported to me that pretests of the new GNU make are about 25x
(or more) slower (for at least some common cases) than the 3.76.1
version.

I have determined that the slowdown is due to the new globbing code I
pulled from the glibc area.

In the old version, I'd call glob() with arguments like this:

  glob(pattern=0x46ef8 "0010.d", flags=528, errfunc=0, pglob=0xefffe850)

and it would complete very quickly: it called glob_in_dir(), immediately
determined there was no meta-chars, and basically be done; the code in
glob_in_dir() was:

     if (!__glob_pattern_p (pattern, !(flags & GLOB_NOESCAPE)))
        {
          stream = NULL;
          flags |= GLOB_NOCHECK;
        }
      else
        {
            ...open dir, run fnmatch(), etc...
        }

Here __glob_pattern_p returns 0, and we skip all the fnmatch() code
completely.

In the new code, it _always_ calls fnmatch() :-/.  It goes like this:

      meta = __glob_pattern_p (pattern, !(flags & GLOB_NOESCAPE));
      if(meta)
	flags |= GLOB_MAGCHAR;

      while (1)
	{
            ...readdir, sanity checks...
	  name = d->d_name;

	  if ((!meta && strcmp (pattern, name) == 0)
	      || fnmatch (pattern, name,
			  (!(flags & GLOB_PERIOD) ? FNM_PERIOD : 0) |
			  ((flags & GLOB_NOESCAPE) ? FNM_NOESCAPE : 0)
#if defined _AMIGA || defined VMS
			  | FNM_CASEFOLD
#endif
			 ) == 0)
	    {

The condition on this if-statement is bogus; it will _always_ call
fnmatch() unless there are no meta chars in the name _AND_ it's the name
we're looking for; my directory has 500 files, so I'm calling fnmatch()
constantly when I don't even have any meta-chars.  This can't be right,
can it?

I think the conditional needs to be:

	  if ((!meta && strcmp (pattern, name) == 0)
	      || (meta && fnmatch (pattern, name,
                    ...

instead--this code has changed a lot, though, and I don't have time to
follow all the permutations :)

Let me know when you have a fix, so I can get it into GNU make before
the next release, thanks...

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@baynetworks.com>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.