more: latest glibc glob code broken

["Paul D. Smith" <psmith@BayNetworks.COM>]

I made that change to avoid unnecessary fnmatch() calls, but the code is
still a lot slower--maybe almost twice as fast as it was before, but
that's still 12x or more slower than the old code :-/.

It appears to be an issue with glob called with GLOB_NOCHECK.  In the
old code there was a special case: if NOCHECK was set and there were no
globbing chars, it didn't even bother looking for the file; it just
returned it.

In the new version, it _does_ look for the file.  Then, after all that
looking, if it's not found it just copies over the file anyway (if
GLOB_NOCHECK is set).  So if there are no meta chars the results will be
the same (the single file name) whether or not the file is found in the
directory!!

So, why bother to spend the time searching it?

I think that special case handling of this situation (no meta-chars and
the NOCHECK flag set) that used to be available needs to be reinstated,
unless there's some subtlety to NOCHECK that I'm not aware of.  The docs
for NOCHECK say:

 GLOB_NOCHECK
    If the pattern doesn't match any file names, return the pattern
    itself as if it were a file name that had been matched.  (Normally,
    when the pattern doesn't match anything, @code{glob} returns that
    there were no matches.)

so the old behavior seems logical to me: in the absence of meta-chars
the exact name will be returned regardless of whether it exists or not.
So you don't even have to look for it.

Please let me know your opinions.

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