Karl Williamson wrote:
> On 12/03/2014 01:29 PM, Father Chrysostomos wrote:
> > The malformations in the string seem to come from the \200 and \237
> > in the input. The only non-\x escapes that survive are \000 and \cA.
> > Note that the two problematic escapes are outside the ASCII range (on
> > ASCII platforms). How is EBCDIC supposed to work when you combine
> > \x{wide} with \234 in the same literal string?
>
> Same as for non-EBCDIC. The whole string is upgraded to UTF-8,
> including the character whose representation is \234. (Actually it is
> UTF-EBCDIC, which is like UTF-8 but the internal bytes are different,
> but the differences should be transparent to anyone who isn't playing
> around with the internal representations, by, e.g. 'use bytes' or
> qr/\C/). XS code could get tripped up if it isn't using the proper
> macros which make things transparent, but I didn't see that this was
> calling XS code.
Look at sub const in Deparse.pm. Could
'if ($str =~ /[[:^print:]]/) {' be the problem?
> The failing test is:
>
> # make sure regexp warnings are reported on the right line
> # (we don't care what warning; the 32768 limit is just one
> # that was easy to reproduce) */
> {
> use warnings;
> my $w;
> local $SIG{__WARN__} = sub { $w = "@_" };
> my $qr = qr/(??{'a'})/;
> my $filler = 1;
> ("a" x 32_769) =~ /^$qr(ab*)+/; my $line = __LINE__;
> like($w, qr/recursion limit.* line $line\b/, "warning on right line");
> }
>
> This large string is exceeding os390 limits. (Actually, you can see
> I've tried cutting it down to just over the size where it triggers the
> desired warning, and it still is exceeding the limits.) The comment
> suggests some other warning would be suitable. I can skip this test on
> EBCDIC, or it could be changed to trigger some other warning. I'd like
> advice on such another warning.
I was hoping for something more exciting. :-)
The only other run-time regexp warning I see is 'Matched non-Unicode
code point'. Does that work for you?
