| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | regcomp: propagate allocation failures•••The error code of an allocating function was not checked in tre_add_tag.
| Szabolcs Nagy | 2015-09-24 | 1 | -1/+2 |
| * | regex: fix character class repetitions•••Internally regcomp needs to copy some iteration nodes before
translating the AST into TNFA representation.
Literal nodes were not copied correctly: the class type and list
of negated class types were not copied so classes were ignored
(in the non-negated case an ignored char class caused the literal
to match everything).
This affects iterations when the upper bound is finite, larger
than one or the lower bound is larger than one. So eg. the EREs
[[:digit:]]{2}
[^[:space:]ab]{1,4}
were treated as
.{2}
[^ab]{1,4}
The fix is done with minimal source modification to copy the
necessary fields, but the AST preparation and node handling
code of tre will need to be cleaned up for clarity.
| Szabolcs Nagy | 2015-03-27 | 1 | -0/+5 |
| * | do not treat \0 as a backref in BRE•••The valid BRE backref tokens are \1 .. \9, and 0 is not a special
character either so \0 is undefined by the standard.
Such undefined escaped characters are treated as literal characters
currently, following existing practice, so \0 is the same as 0.
| Szabolcs Nagy | 2015-03-23 | 1 | -1/+1 |
| * | suppress backref processing in ERE regcomp•••one of the features of ERE is that it's actually a regular language
and does not admit expressions which cannot be matched in linear time.
introduction of \n backref support into regcomp's ERE parsing was
unintentional.
| Rich Felker | 2015-03-20 | 1 | -1/+1 |
| * | fix memory-corruption in regcomp with backslash followed by high byte•••the regex parser handles the (undefined) case of an unexpected byte
following a backslash as a literal. however, instead of correctly
decoding a character, it was treating the byte value itself as a
character. this was not only semantically unjustified, but turned out
to be dangerous on archs where plain char is signed: bytes in the
range 252-255 alias the internal codes -4 through -1 used for special
types of literal nodes in the AST.
| Rich Felker | 2015-03-20 | 1 | -1/+1 |
| * | rewrite the regex pattern parser in regcomp•••The new code is a bit simpler and the generated code is about 1KB
smaller (on i386). The basic design was kept including internal
interfaces, TNFA generation was not touched.
The old tre parser had various issues:
[^aa-z]
negated overlapping ranges in a bracket expression were handled
incorrectly (eg [^aa-z] was handled as [^a] instead of [^a-z])
a{,2}
missing lower bound in a counted repetition should be an error,
but it was accepted with broken semantics: a{,2} was treated as
a{0,3}, the new parser rejects it
a{999,}
large min count was not rejected (a{5000,} failed with REG_ESPACE
due to reaching a stack limit), the new parser enforces the
RE_DUP_MAX limit
\xff
regcomp used to accept a pattern with illegal sequences in it
(treated them as empty expression so p\xffq matched pq) the new
parser rejects such patterns with REG_BADPAT or REG_ERANGE
[^b-fD-H] with REG_ICASE
old parser turned this into [^b-fB-F] because of the negated
overlapping range issue (see above), the new parser treats it
as [^b-hB-H], POSIX seems to require [^d-fD-F], but practical
implementations do case-folding first and negate the character
set later instead of the other way around. (Supporting the posix
way efficiently would require significant changes so it was left
as is, it is unclear if any application actually expects the
posix behaviour, this issue is raised on the austingroup tracker:
http://austingroupbugs.net/view.php?id=872 ).
another case-insensitive matching issue is that unicode case
folding rules can group more than two characters together while
towupper and towlower can only work for a pair of upper and
lower case characters, this is a limitation of POSIX so it is
not fixed.
invalid bracket and brace expressions may return different error
codes now (REG_ERANGE instead of REG_EBRACK or REG_BADBR instead
of REG_EBRACE) otherwise the new parser should be compatible with
the old one.
regcomp should be able to handle arbitrary pattern input if the
pattern length is limited, the only exception is the use of large
repetition counts (eg. (a{255}){255}) which require exp amount
of memory and there is no easy workaround.
| Szabolcs Nagy | 2014-09-13 | 1 | -1068/+621 |
| * | include cleanups: remove unused headers and add feature test macros | Szabolcs Nagy | 2013-12-12 | 1 | -1/+0 |
| * | fix allocation sizes in regcomp•••sizeof had incorrect argument in a few places, the size was always
large enough so the issue was not critical.
| Szabolcs Nagy | 2013-10-07 | 1 | -4/+4 |
| * | remove unused "params" related code from regex•••some structs and functions had reference to the params
feature of tre that is not used by the code anymore
| Szabolcs Nagy | 2013-01-15 | 1 | -20/+11 |
| * | use restrict everywhere it's required by c99 and/or posix 2008•••to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
| Rich Felker | 2012-09-06 | 1 | -1/+1 |
| * | remove some no-op end of string tests from regex parser•••these are cruft from the original code which used an explicit string
length rather than null termination. i blindly converted all the
checks to null terminator checks, without noticing that in several
cases, the subsequent switch statement would automatically handle the
null byte correctly.
| Rich Felker | 2012-05-13 | 1 | -4/+0 |
| * | another BRE fix: in ^*, * is literal•••i don't understand why this has to be conditional on being in BRE
mode, but enabling this code unconditionally breaks a huge number of
ERE test cases.
| Rich Felker | 2012-05-13 | 1 | -0/+2 |
| * | fix error checking for \ at end of regex (this was broken previously) | Rich Felker | 2012-05-07 | 1 | -1/+1 |
| * | fix copy and paste error in regex code causing mishandling of \) in BRE | Rich Felker | 2012-05-07 | 1 | -1/+1 |
| * | fix regex breakage in last commit (failure to handle empty regex, etc.) | Rich Felker | 2012-05-07 | 1 | -4/+1 |
| * | fix ugly bugs in TRE regex parser•••1. * in BRE is not special at the beginning of the regex or a
subexpression. this broke ncurses' build scripts.
2. \\( in BRE is a literal \ followed by a literal (, not a literal \
followed by a subexpression opener.
3. the ^ in \\(^ in BRE is a literal ^ only at the beginning of the
entire BRE. POSIX allows treating it as an anchor at the beginning of
a subexpression, but TRE's code for checking if it was at the
beginning of a subexpression was wrong, and fixing it for the sake of
supporting a non-portable usage was too much trouble when just
removing this non-portable behavior was much easier.
this patch also moved lots of the ugly logic for empty atom checking
out of the default/literal case and into new cases for the relevant
characters. this should make parsing faster and make the code smaller.
if nothing else it's a lot more readable/logical.
at some point i'd like to revisit and overhaul lots of this code...
| Rich Felker | 2012-05-07 | 1 | -60/+31 |
| * | remove invalid code from TRE•••TRE wants to treat + and ? after a +, ?, or * as special; ? means
ungreedy and + is reserved for future use. however, this is
non-conformant. although redundant, these redundant characters have
well-defined (no-op) meaning for POSIX ERE, and are actually _literal_
characters (which TRE is wrongly ignoring) in POSIX BRE mode.
the simplest fix is to simply remove the unneeded nonstandard
functionality. as a plus, this shaves off a small amount of bloat.
| Rich Felker | 2012-04-13 | 1 | -14/+0 |
| * | upgrade to latest upstream TRE regex code (0.8.0)•••the main practical results of this change are
1. the regex code is no longer subject to LGPL; it's now 2-clause BSD
2. most (all?) popular nonstandard regex extensions are supported
I hesitate to call this a "sync" since both the old and new code are
heavily modified. in one sense, the old code was "more severely"
modified, in that it was actively hostile to non-strictly-conforming
expressions. on the other hand, the new code has eliminated the
useless translation of the entire regex string to wchar_t prior to
compiling, and now only converts multibyte character literals as
needed.
in the future i may use this modified TRE as a basis for writing the
long-planned new regex engine that will avoid multibyte-to-wide
character conversion entirely by compiling multibyte bracket
expressions specific to UTF-8.
| Rich Felker | 2012-03-20 | 1 | -771/+818 |
| * | duplicate re_nsub in LSB/glibc ABI compatible location | Rich Felker | 2011-06-16 | 1 | -1/+1 |
| * | initial check-in, version 0.5.0 | Rich Felker | 2011-02-12 | 1 | -0/+3362 |
