Skip to content
This repository
Browse code

Add test for regexp eval fail

  • Loading branch information...
commit f2025c2745c4e412b57733351b7c32d9cc2a21ce 1 parent 8b7484f
Florian Ragwitz rafl authored

Showing 3 changed files with 39 additions and 2 deletions. Show diff stats Hide diff stats

  1. +1 1  .gitignore
  2. +1 1  Makefile.PL
  3. +37 0 t/regexp_eval.t
2  .gitignore
@@ -8,7 +8,7 @@ Makefile
8 8 Makefile.old
9 9 blib/
10 10 cover_db/
11   -t/
  11 +t/e2e/
12 12 lib/Devel/Cover/Inc.pm
13 13 pm_to_blib
14 14 *.out
2  Makefile.PL
@@ -372,7 +372,7 @@ WriteMakefile
372 372 "Digest::MD5" => 0,
373 373 },
374 374 dist => { COMPRESS => "gzip --best --force" },
375   - test => { TESTS => "t/*/*.t" },
  375 + test => { TESTS => "t/*/*.t t/*.t" },
376 376 clean => { FILES => join " ", "t/e2e/*" },
377 377 depend => { distdir => "@files" },
378 378 realclean => $] < 5.008008 ?
37 t/regexp_eval.t
... ... @@ -0,0 +1,37 @@
  1 +use strict;
  2 +use warnings;
  3 +use Test::More tests => 1;
  4 +
  5 +# This tests against what is basically a perl bug. When evaluating
  6 +# code within a regular expression, the state of the regular
  7 +# expression engine may not be altered, i.e. no regex match may be
  8 +# performed within a regular expression.
  9 +#
  10 +# The following code doesn't do that, but entering the eval within the
  11 +# regular expression involves a nextstate OP. We hook, among other
  12 +# things, into those opcodes, and execute some of our own
  13 +# code. Devel::Cover::use_file, to be precise. That function currently
  14 +# uses regular expressions, and therefore breaks shit.
  15 +#
  16 +# We currently avoid calling use_file at all within regexp evals. This
  17 +# test makes sure we actually do, and will yell at us if we ever start
  18 +# doing it again.
  19 +#
  20 +# CPAN RT#57174 is the corresponding Devel::Cover bug. This still
  21 +# needs to be submitted to and fixed in perl core.
  22 +
  23 +'x' =~ m{ (?: ((??{ 'x' })) )? }x;
  24 +
  25 +# on debugging perls we'd already have hit an assertion failure
  26 +# here. We don't do "pass 'no assertion fail'" tho. I don't know if
  27 +# that might mess up $1 for the next test. We also have to use $1
  28 +# instead of capturing in a lexical, as that tends to fail rather
  29 +# differently.
  30 +
  31 +# on non-debugging perls, the above match tends to succeed, and only
  32 +# rarely segfaults. Therefore we also make sure that the result is
  33 +# correct. If we hit the bug, it tends to either contain complete
  34 +# garbage, (parts of) some random constants from the perl interpreter,
  35 +# or segfaults completely when invoking the get magic on it.
  36 +
  37 +is $1, 'x';

0 comments on commit f2025c2

Please sign in to comment.
Something went wrong with that request. Please try again.