Front page | perl.perl5.porters |
Postings from October 2016
On 18 October 2016 at 03:17, Father Chrysostomos via RT
<perlbug-followup@perl.org> wrote:
> On Mon Oct 17 10:26:19 2016, brian.carpenter@gmail.com wrote:
>> I'm not convinced that this is an actual bug,
>
> I think it is.
>
>> but #p5p was silent when I
>> asked about it. Affects Perl back to 5.20.2 including v5.25.6
>> (v5.25.5-114-g87af8d5). Valgrind fails pretty quickly but gdb just goes on
>> forever.
>>
>> perl -e '/0'
>
> That is nonsensical code.
Do you mean just the '/0' or the full pattern?
With some editing I read the original code as being the same as
(m/(?{
m!(0)!,
s!!!
})/) / 0
Which is strange but IMO valid code.
> $ perl5.18.3 -e '/(?{m}(0)},s\/\/\/})//0'
> Segmentation fault: 11
> $ perl5.14.4 -e '/(?{m}(0)},s\/\/\/})//0'
> Sequence (?{...}) not terminated or not {}-balanced in regex; marked by <-- HERE in m/(?{ <-- HERE m}(0)},s///})/ at -e line 1.
>
> I do not have 5.16 handy. The output from 5.14 is what I would expect.
I am not sure why. Is it because you expect the first } to close the
(?{ , while I dont? The inside of the (?{ ... }) is code, and should
follow nesting rules, so m}(0)} should be parsed and extracted as a
balanced construct, just as it would if it were q}foo}, and then the
s/// gets parsed out, to find the trailing }) which finish the (?{})
construct.
I would say the 5.14.4 behavior is a misparse.
If this is legal:
perl -le'print q}foo}'
foo
then I would expect this:
m}(0)}
to be legal too, and i would expect it to be legal inside of a (?{ ...
}) construct in a pattern.
>> ==6615==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc78f88ca8
>> (pc 0x0000004c0d4c bp 0x7ffc78f89500 sp 0x7ffc78f88cb0 T0)
>> #0 0x4c0d4b in calloc (/root/perl/perl+0x4c0d4b)
>> #1 0x7f9301 in Perl_safesyscalloc /root/perl/util.c:442:18
>> #2 0xb45aed in Perl_regexec_flags /root/perl/regexec.c:3128:9
>> #3 0x8cf9c5 in Perl_pp_subst /root/perl/pp_hot.c:2981:10
>> #4 0x7f4483 in Perl_runops_debug /root/perl/dump.c:2246:23
>> #5 0xb984b6 in S_regmatch /root/perl/regexec.c:6888:3
>> #6 0xb7337c in S_regtry /root/perl/regexec.c:3622:14
>
> It should not even be getting that far. It should fail at compile time.
Looking forward to hearing more on why.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next