fix ugly bugs in TRE regex parser
authorRich Felker <dalias@aerifal.cx>
Mon, 7 May 2012 18:50:49 +0000 (14:50 -0400)
committerRich Felker <dalias@aerifal.cx>
Mon, 7 May 2012 18:50:49 +0000 (14:50 -0400)
commitd7a90b35b9b5336a3e730e09d56f1c53f4e946ee
tree9352610f23666ee1e0427d90b7ab12aeb8469592
parent2d3e2a7fc13296bb682b9a48b81f1c7130a94bde
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...
src/regex/regcomp.c