Front page | perl.perl5.porters |
Postings from October 2017
On Tue, 26 Sep 2017 10:31:43 -0700, atoomic wrote: > I agree with Tony Cook this is a problem in REPORT_LOCATION_ARGS, > when calling vFAIL2 from S_grok_bslash_N > > 1/ minor, we should not use vFAIL2 as the second arg is a 'N', the > vFAIL is probably more appropriate there. > > 2/ I confirm that using FAIL or FAIL2 instead of the vFAIL family > fixes the issue > > I think the problem is to use a negative offset for the length in > REPORT_LOCATION_ARGS (view attached patch) > > note, as it a few tests are failing from re/regexp.t & co, can adjust > them, but want to confirm that the suggested patch is correct first > I finally had a good look at this problem. It turns out that the code patch is not the correct fix. It causes valgrind errors when I run it, and there is instead a deeper problem. The patch substitutes 0 when a number is negative. But it turns out that if the number is negative, it means something is terribly wrong. I will submit a patch that asserts against that. I thought I understood why this number is getting negative, but now I realize that I still don't understand that. It turns out that I have been overhauling this area of the code for other reasons, and the most productive path forward is to start with the overhaul that I've done so far. I'll look at the .t patch after that is done. The reason for the vFAIL2 instead of the more obvious vFAIL is so that the existing entry in perldiag would work. Extra entries slow down the process for someone trying to figure out what's going on, and when I wrote the code I thought the tradeoff was worthwhile, to improve the user experience. Since we are about to croak, there's no performance impetus. The other option would have been to add a 'diag listed as' comment there. I try to avoid those. But I could have added an explanation why the non-obvious thing was done. -- Karl Williamson --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=132163