Re^2: [bugs?] perldoc perlre, \G and pos()

Replies are listed 'Best First'.
Re^3: [bugs?] perldoc perlre, \G and pos() by ikegami (Patriarch) on Sep 29, 2009 at 15:22 UTC
Like I said, GIGO. You're trying to make it start and end at pos -1 An endless loop could only be a result of infinitely repeating matches not of the opposite. I said it thinks it hasn't matched yet. A reasonable belief when pos == 0.	[reply]
Re^4: [bugs?] perldoc perlre, \G and pos() by LanX (Saint) on Sep 29, 2009 at 15:29 UTC
And I said if it "thinks it hasn't matched yet" the while condition is false not true! Cheers Rolf	[reply]
Re^5: [bugs?] perldoc perlre, \G and pos() by ikegami (Patriarch) on Sep 29, 2009 at 15:31 UTC
1st Pass: It thinks it hasn't matched yet because pos == 0, so it matches, setting pos = 0. 2nd Pass: It thinks it hasn't matched yet because pos == 0, so it matches, setting pos = 0. 3rd Pass: It thinks it hasn't matched yet because pos == 0, so it matches, setting pos = 0. ...	[reply]
Re^6: [bugs?] perldoc perlre, \G and pos() by LanX (Saint) on Sep 29, 2009 at 15:35 UTC
Re^7: [bugs?] perldoc perlre, \G and pos() by ikegami (Patriarch) on Sep 29, 2009 at 16:07 UTC
Some notes below your chosen depth have not been shown here
Re^3: [bugs?] perldoc perlre, \G and pos() by JavaFan (Canon) on Sep 29, 2009 at 21:11 UTC
It's not that I care so much which result it produces, as long as they are consistent! I much rather have bugs that produce inconsistent results than consistent results. If it produces consistent results, there will be code that relies on it, and it will (politically) harder to fix the bug. If the results were inconsistent anyway, fixing the bug is very unlikely to break existing code.	[reply]
Re^4: [bugs?] perldoc perlre, \G and pos() (why consistency counts) by LanX (Saint) on Sep 30, 2009 at 12:49 UTC
A very good - "political"- point! 8) Anyway I didn't say that consistency is more important than functionality! Let me explain .. if we're talking about rare edge cases any consistent output can be - from a higher point of view - a valid interpration. An example, lets take a binary operator `x` which is used on two boole values A and B, such that `X 0 1 B - - 0\|0 1 1\|1 ? A` [download] `?` denotes the edgecase of A=B=1 - in ikegamis words GI (=garbage input) - which produces inconsistent output, sometimes 0 sometimes 1, which causes many people to avoid this unpredictable operator. Now surprisingly making it consistent is always a win. With ?=1 we get the OR operator, with ?=0 it's XOR! Ok it's a simplified example, our case is more complicated, but I hope you get my point, why consistency is -technically - a win. In our problem ? Well it's the edge case of resetting pos. The result of the next match is inconsistent for an input of pos=undef and pos=0, which doesn't really make much sense. So consistency is the first step on the way to kill bugs, your point is more about if improvements should be done step by step! Cheers Rolf	[reply] [d/l] [select]
Re^5: [bugs?] perldoc perlre, \G and pos() (why consistency counts) by JavaFan (Canon) on Sep 30, 2009 at 14:19 UTC
Ok it's a simplified example, our case is more complicated, but I hope you get my point, why consistency is -technically - a win. Only from a language user point of view. For instance, in C (and its equivalent in Perl), the result of `i = i++;` is not defined, so it doesn't need to be consistent. This leaves compiler implementors freedom - this freedom may lead to faster code. A more Perlish example is order in which `keys()` return the keys of a hash. Because the order was never defined to be consistent, a security feature (making certain DoS attacks much harder) could have been implemented between 5.8.0 and 5.8.1 (that is, in 2003), instead of having to have 5.10 being a deprecation cycle, and having to wait till 5.12 for an implementation of this fix. Of course, that's on top of the already existing benefit of `keys()` being faster if there's no guaranteed order. Now, I don't want to deny that consistency is usually a good thing. I just don't agree it's always a win.	[reply] [d/l] [select]
Re^3: [bugs?] perldoc perlre, \G and pos() by ikegami (Patriarch) on Sep 29, 2009 at 15:23 UTC
Like I said, GIGO. You're trying to make it start and end at pos -1 An endless loop could only be a result of infinitely repeating matches not of the opposite. I said it thinks it hasn't matched yet. A reasonable belief when pos == 0.	[reply]