POSIX allows a reversed-order range to be treated as invalid (forcing
the bracket to be interpreted as a literal) or as valid but not
matching any characters. because we matched the starting character of
the range before identifying it as a range, however, [z-a] would match
'z'.

explicitly check for a subsequent non-terminal '-', and don't match if
one is present. the match, if any, will be caught by the range logic
in the next iteration.

the advancement logic was off-by-one, accounting for the p++ in the
for clause but not the '-' character. this resulted in attempting to
process the last byte of the range endpoint on the next iteration of
the loop.

for a single-byte endpoint this was harmless, but for a multi-byte
character, mbtowc would fail on the next iteration, preventing
matching of any subsequent part of the bracket.

the new condition also allows forward progress into ordinary matching
if the pattern begins with a backslash. this is fine independent of
FNM_NOESCAPE and independent of what follows the backslash; if
FNM_NOESCAPE is active, the backslash is literal and will not match.
if FNM_NOESCAPE is not active, the pattern beginning with a backslash
ensures that the first character is literal.

at least gai_strerror() and regerror() are specified to accept any int
value. if the value was close to INT_MAX (for gai_strerror()) or
INT_MIN (for hstrerror() and regerror()) a signed integer overflow
would occur.

fix this by converting the int argument to unsigned before doing
arithmetic.

in BRE \n matches the nth subexpression, but regcomp did not check if
the nth subexpression was complete or not, only that there were more
subexpressions overall than the largest backref.

fix regcomp to error if the referenced subexpression is incomplete.
the bug could cause an infinite loop in regexec:

 regcomp(&re, "\\(^a*\\1\\)*", 0);
 regexec(&re, "aa", 0, 0, 0);

since BRE has backreferences, any application accepting a BRE from
untrusted sources is already vulnerable to an attacker-controlled
near-infinite (exponential-time) loop, but this particular case where
the loop is actually infinite can and should be avoided.

ERE is not affected since the language an ERE describes is actually
regular.

Reported-by: Simon Resch <simon.resch@code-intelligence.com>

when the result count was zero, glob was ignoring a possible
GLOB_ABORTED error code and returning GLOB_NOMATCH. whether this
happened could be nondeterministic and dependent on the order of
dirent enumeration, in cases where multiple matches were present and
only some produced errors.

caught by Tor's test_util_glob.

originally the namespace-infringing "large file support" interfaces
were included as part of glibc-ABI-compat, with the intent that they
not be used for linking, since our off_t is and always has been
unconditionally 64-bit and since we usually do not aim to support
nonstandard interfaces when there is an equivalent standard interface.

unfortunately, having the symbols present and available for linking
caused configure scripts to detect them and attempt to use them
without declarations, producing all the expected ill effects that
entails.

as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made
to prevent this, using macros to redirect the LFS64 names to the
standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE.
however, this has turned out to be a source of further problems,
especially since g++ defines _GNU_SOURCE by default. in particular,
the presence of these names as macros breaks a lot of valid code.

this commit removes all the LFS64 symbols and replaces them with a
mechanism in the dynamic linker symbol lookup failure path to retry
with the spurious "64" removed from the symbol name. in the future,
if/when the rest of glibc-ABI-compat is moved out of libc, this can be
removed.

when the pattern ended with one or more literal path components, or
when the GLOB_MARK flag was passed to request that glob flag directory
results and the type obtained by readdir was unknown or inconclusive
(symlink), the stat function was called to evaluate existence and/or
determine type. however, stat fails with ENOENT for broken symlinks,
and this caused the match to be omitted from the results.

instead, use stat only for the unknown/inconclusive cases with
GLOB_MARK, and otherwise, or if stat fails, use lstat existence still
needs to be determined. this minimizes the number of costly syscalls,
performing both only in the case where GLOB_MARK is in use and there
is a final literal path component which is a broken symlink.

based on/simplified from patch by James Y Knight.

previously (before and after rewrite), spurious escaping of path
separators as \/ was not treated the same as /, but rather got split
as an unpaired \ at the end of the fnmatch pattern and an unescaped /,
resulting in a mismatch/error.

for the case of \/ as part of the maximal literal prefix, remove the
explicit rejection of it and move the handling of / below escape
processing.

for the case of \/ after a proper glob pattern, it's hard to parse the
pattern, so don't. instead cheat and count repetitions of \ prior to
the already-found / character. if there are an odd number, the last is
escaping the /, so back up the split position by one. now the
char clobbered by null termination is variable, so save it and restore
as needed.