From: Robert Klemme <shortcutter@...>
Date: 2010-11-24T22:56:57+09:00
Subject: Re: Regex negative look-behind bug?

On Wed, Nov 24, 2010 at 1:32 PM, Ammar Ali <ammarabuali@gmail.com> wrote:
> On Wed, Nov 24, 2010 at 12:57 PM, Robert Klemme
> <shortcutter@googlemail.com>wrote:
>
>> On Tue, Nov 23, 2010 at 5:12 PM, Ammar Ali <ammarabuali@gmail.com> wrote:
>> >
>> > The thing is what's in the lookbehind, and all assertions for that
>> matter,
>> > is not really a regular expression. It is a fixed length literal. The
>> only
>> > exception, AFAIK, is character sets because they are also fixed length.
>> The
>> > engine needs to know how many characters to step back and examine.
>>
>> Docs say that the regexp cannot be unlimited.  But it is by far not
>> only a fixed length literal.  "|" is certainly meta in an assertion -
>> the second line would not match if the lookbehind assertion was a
>> literal.
>
> Yes, please excuse the terseness of my last response. I wrote it as I was
> rushing out the door.

Probably not the best thing to do.  I know.  It has happened to me as well. :-)

> What I meant, but did not properly clarify, is; the contents of assertions
> are not *full* expressions. They can not contain quantifiers, they can not
> contain captures, and they can not include backreferences or anything that
> can complicate determining the length of the contents. Obviously alternation
> is allowed, since that's what we were discussing. However, only as long as
> the alternatives abide by the limitations.
>
> Ruby's regular expression engine is quite flexible in this regard, as it
> allows the alternatives to be of different lengths, unlike some other
> engines that require them to be of the same length.
>
>
> ----8<----
>
>> The root issue still exists
>>
>> irb(main):014:0> "a ac".scan /(?<!a a|b)c/i
>> => []
>> irb(main):015:0> "A Ac".scan /(?<!a a|b)c/i
>> => ["c"]
>> irb(main):016:0> "ac".scan /(?<!a|b)c/i
>> => []
>> irb(main):017:0> "Ac".scan /(?<!a|b)c/i
>> => []
>>
>> ----8<----
>
>
>>
>> IMHO this is a bug.
>
> OK, now that we've eliminated the syntax and the double-negative confusion,
> I see the issue clearly. Thank you for your patience :)

YWC.

> It might be a bug, but since the contents of assertions do not go through
> the full eval/exec cycle of "regular" regular expressions, this could be
> just another limitation of assertions. It might be difficult to figure out
> the last options in effect because they can be inserted multiple times in an
> expression, on their own (from here on) and they can be nested. Which of
> these would be used? Maybe just use the top level options? That can
> potentially introduce more confusion.

I don't see any difference in finding out options to other grouping
constructs: the innermost surrounding flags should be used.  Every
other rule would be utmost confusing.

irb(main):002:0> "aBc".scan /(?i:a(?:b)c)/
=> ["aBc"]

irb(main):005:0> "abCde".scan /(?-i:a(?i:b(?:c)d)e)/i
=> ["abCde"]
irb(main):008:0> "abCde".scan /a(?i:b(?:c)d)e/
=> ["abCde"]

> Anyway, it's definitely worth reporting. Worst case, we'll find out it's a
> limitation, and best case, it will end being a feature request, if not a
> bug.

I vote for "bug". :-)

> Is the OP able/willing to report this?
>
>  http://redmine.ruby-lang.org/

Please, do.

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/