bug#16895: [PATCH] grep: fix multiple bugs with bracket expressions

[Paul Eggert]

On 02/27/2014 12:31 PM, Aharon Robbins wrote:
> What a mouthful!  Is all that really necessary?

You should have seen it before I trimmed it down; it listed every POSIX 
character.  I dunno, maybe it could be trimmed, but I was worried about 
oddball character sets like the unibyte JIS character set that's like 
ASCII but substitutes Yen-sign for '\', and a couple of other 
substitutions like that.  I figured better safe than sorry.  No big deal 
of course.

> I'd suggest parentheses around the bit with the bitwise operator, both 
> for readability and to match the rest of the code. 

Done, with the attached patch.  Oh, and I fixed an xdigit buglet I found 
too, in the second patch in the attachment.

> > >@@ -1000,7 +1043,10 @@ parse_bracket_exp (void)
> > >                /* Fetch bracket.  */
> > >                FETCH_WC (c, wc, _("unbalanced ["));
> > >                if (c1 == ':')
> > >-                /* build character class.  */
> > >+                /* Build character class.  POSIX allows character
> > >+                   classes to match multicharacter collating elements,
> > >+                   but the regex code does not support that, so do not
> > >+                   worry about that possibility.  */
> I thought GLIBC did support them?
Source code says no.  That is, [[:alpha:]] never matches a 
multicharacter collating sequence.  [[=a=]] might do so, but [[:alpha:]] 
doesn't.  (Unless I'm reading the source code wrong, which is possible.  
It's not documented either way, as far as I know.)

grep.diff
Description: Text Data