in reply to Re: Re: Risks in the oblivious use of qr//
in thread Risks in the oblivious use of qr//

hmm, are you saying that: 
$myregex = qr/test/i;
if (/$myregex = yes/) {...}

[download]
should or should not be case insensitive for the /test/ part of the regex? to me the lack of options at the end of a regex means dont use them, but it makes sence to me that the precompiled regex would force the flags given to it. I dont see the bug there...

-Waswas

Replies are listed 'Best First'.
Re: Re: Re: Re: Risks in the oblivious use of qr//
by diotalevi (Canon) on Aug 11, 2003 at 11:55 UTC

    My thinking is that affirmatively setting a flag should override. Since there is no way to positively unset a flag I would expect this to be a case insensitive match. Similarly, if you swapped /i between the expressions I would still expect this to be case insensitive.

    Added: I'm going to moderate my opinion here. I thought a bit further and on consideration, the flags /s, /m and /x are likely not safe to have a locally specified flag override. The only qr// flag that could sanely be overridden is /i and in this case I still call the current behaviour a bug.

[reply]

      The only qr// flag that could sanely be overridden is /i and in this case I still call the current behaviour a bug.

      Nope. I disagree. If thats a bug then there would be no way to disable /i from inside the regex when the i modifier is used. Which would totally break quite a few regexes that I have. And conversly, would putting a regex compiled with /i into a regex without /i cause the i to cease functioning? Definately not a bug.


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
[reply]
[d/l]

        I'm taking a positivist approach to this. Where /i is specified it overrides, where it is not, it doesn't. So /$re/i has a local definition of /i but /$re/ doesn't. This implies that where a local redefinition occurs you've gained nothing in performance because the regex fragment must be recompiled to match the local expectations. I think that's just too bad. The alternative viewpoints here might be that the potential performance hit is unacceptable (even given the logical disconnect) or that a a regex fragment is actually a universe unto itself and just because it is included in a larger regex the larger regex's rules shouldn't apply.

        I'm still holding out for a positivist interpretation of this.

[reply]
      I guess my expectations would be precompiled regex are static and immutable in both shape and flag options so the behavior makes sense to me. how would you reap any speed benefit if the interpreter had to reevaluate all locations where qr//'ed regex were used to recompile and apply flags?

      -Waswas
[reply]

        You wouldn't.

[reply]

In Section Meditations