Handle overloading properly in compile-time regex
authorDavid Mitchell <davem@iabyn.com>
Thu, 28 Mar 2013 14:11:16 +0000 (14:11 +0000)
committerDavid Mitchell <davem@iabyn.com>
Fri, 12 Apr 2013 10:29:55 +0000 (11:29 +0100)
commit55269f4f7ec374aedc4b04fe74db5d9f3a2886d6
tree42f3aa1df68d81a7f0279382d7e4f297e3f2faec
parentfaa0d3c9abc8a0214e2478797030c3300a58989e
Handle overloading properly in compile-time regex

[perl #116823]

In re_op_compile(), there were two different code paths for compile-time
patterns (/foo(?{1})bar/) and runtime (/$foo(?{1})bar/).

The code in question is where the various components of the pattern
are concatenated into a single string, for example, 'foo', '(?{1})' and
'bar' in the first pattern.

In the run-time branch, the code assumes that each component (e.g. the
value of $foo) can be absolutely anything, and full magic and overload
handling is applied as each component is retrieved and appended to the
pattern string.

The compile-time branch on the other hand, was a lot simpler because it
"knew" that each component is just a simple constant SV attached to an
OP_CONST op. This turned out to be an incorrect assumption, due to
overload::constant qr overloading; here, a simple constant part of a
compile-time pattern, such as 'foo', can be converted into whatever the
overload function returns; in particular, an object blessed into an
overloaded class. So the "simple" SVs that get attached to OP_CONST ops
can in fact be complex and need full magic, overloading etc applied to
them.

The quickest solution to this turned out to be, for the compile-time case,
extract out the SV from each OP_CONST and assemble them into a temporary
SV** array; then from then onwards, treat it the same as the run-time case
(which expects an array of SVs).
regcomp.c
t/re/overload.t