Re^2: Modifying pos() from within (?{...})

Thanks for this, it's clear and explains why the (?{...}) solution didn't (and could never) work.

I've not used \G and /c before. From reading perlre I now understand that \G essentially 'anchors' that point to index pos() into the string. I'm a little confused by the description for the /c modifier. From perlre v5.24:

c - keep the current position during repeated matching

and from the referenced perlretut

A failed match or changing the target string resets the position. If you don't want the position reset after failure to match, add the "//c", as in "/regexp/gc".

I assume then, should the data I'm parsing with the regex be well formatted, then pos() will never be reset and so the /c modifier is not needed? But were any matches fail, things would break

Is this a correct understanding of \G and /c?

Comment on Re^2: Modifying pos() from within (?{...}) Select or Download Code

Replies are listed 'Best First'.
Re^3: Modifying pos() from within (?{...}) by haukex (Archbishop) on Apr 26, 2018 at 13:50 UTC
I assume then, should the data I'm parsing with the regex be well formatted, then `pos()` will never be reset and so the `/c` modifier is not needed? Note that the condition on the `while` loop is the regex, so the loop will run while the match is true, so the last match executed will always be a failed one. The question then is why it failed, because it reached the end of string (= successful overall parse) or it did not, which is why I compare pos to length - but for pos to be available there, I need `/c`. Read more... demo code (2 kB) Another use for `/c` is described in "`\G` assertion" in perlop (under "Regexp Quote-Like Operators"): basically, attempting to apply multiple different regexes at the same point in a string until you find one that matches.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Modifying pos() from within (?{...})
by haukex (Archbishop) on Apr 26, 2018 at 13:50 UTC

I assume then, should the data I'm parsing with the regex be well formatted, then pos() will never be reset and so the /c modifier is not needed?

Note that the condition on the while loop is the regex, so the loop will run while the match is true, so the last match executed will always be a failed one. The question then is why it failed, because it reached the end of string (= successful overall parse) or it did not, which is why I compare pos to length - but for pos to be available there, I need /c.