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

[Aharon Robbins]

Hi Paul.

> Date: Thu, 27 Feb 2014 13:24:53 -0800
> From: Paul Eggert <address@hidden>
> Organization: UCLA Computer Science Department
> To: Aharon Robbins <address@hidden>, address@hidden
> Subject: Re: bug#16895: [PATCH] grep: fix multiple bugs with bracket 
> expressions

OK - I tried out that patch (+ the two successors) in gawk and
it works fine, even causing a test that failed to now succeed (since
it falls back to regex).  I've merged and pushed the change.
I definitely owe you some beer for this one. :-)

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

Is that done at compile time in those locales, or at run time? What
you've put in is a compile time check.  I ask out of total ignorance
and am wondering how it works.

> >> >-                /* 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.)

Ah. I misunderstood the context. GLIBC does support [[=a=]] and [[.ch.]],
though, right?

Thanks!

Arnold