develooper Front page | perl.perl5.porters | Postings from June 2018

Re: [perl #133239] Very misleading line number for warnings in somecases

Thread Previous | Thread Next
From:
Rocky Bernstein
Date:
June 20, 2018 22:13
Subject:
Re: [perl #133239] Very misleading line number for warnings in somecases
Message ID:
CANCp2gaponfQ5NCDnLQPP-z7JeiCupeRfzty_Bz62eythjhNcg@mail.gmail.com
On Wed, Jun 20, 2018 at 5:19 PM, Eric Brine <ikegami@adaelis.com> wrote:

> On Tue, Jun 19, 2018 at 4:36 AM, Dave Mitchell <davem@iabyn.com> wrote:
>
>> On Fri, Jun 01, 2018 at 03:22:18PM -0700, Stephen E. Dewey (via RT) wrote:
>> > I have provided a full description of the bug on StackOverflow
>> > at https://stackoverflow.com/q/50651331/783314. I will keep that
>> > question up-to-date in case I come across anything new.
>> >
>> > For convenience, here is what I wrote there:
>> > I have isolated a case where Perl provides a very misleading line
>> number in a warning message. I tested the below in Strawberry Perl 5.16.3.
>> >
>> > use strict;
>> > use warnings;
>> >
>> > my $choice = 0;
>> >
>> > while ($choice == 0){
>> >
>> >     #Pretend the user provided this via STDIN
>> >     $choice = '5,6,7';
>> >
>> >     if ($choice eq '-4'){
>> >         print "This isn't going to happen\n";
>> >     }
>> > }
>> >
>> > When you run this, you will get the warning message Argument "5,6,7"
>> isn't numeric in numeric eq (==) at example.pl line 11. But line 11
>> corresponds to the line if ($choice eq '-4'){ which cannot possibly cause
>> this warning message because it does not contain a numeric comparison.
>> >
>> > It seems what's actually happening is that Perl advances to the next
>> comparison, while ($choice == 0){, but the line counter used for the
>> warning message does not advance.
>> >
>> > What makes this particular case worse is that, since the "bad"
>> comparison is the loop condition, it is actually far away from the provided
>> line. In my (pre-simplification) script, it was hundreds of lines away from
>> the provided line number.
>> >
>> > Is this a bug or just an unfortunate limitation of the parser?
>>
>> It's a well-known limitation that needs to be addressed at some point.
>> The current implementation only records the line number of the start of
>> each statement. At runtime, each time the interpreter is about to start
>> executing a statement, it records the line number associated with that
>> statement. In warnings and error messages, the last recorded line number
>> is used.
>>
>
> It's the nextstate ops that record the line numbers, right?
>

Yes, I believe so.


> Couldn't one be added to the start of the while expression?
>
>
Proably - why not make the modification and let us know if that fixes
things?

Note though that in  https://stackoverflow.com/a/50651543/546218 another
possibility was mentioned and used in Perl 5.006: add a nextstate to the
end of the loop. There are probably other possibilities as well.

That said, I think it was Reini Urban who mentioned that adding
nextstate/dbstate as instructions in the optree rather than as a side table
outside of the optree slows execution down for various reasons that he can
probably better elaborate on.

One of the cool things about using this novel decompilation at runtime
technique is that you can get greater accuracy in location while also
reducing runtime overhead in the normal cases when there are no warnings or
errors. And it works when there is no source code file such as inside
eval().

Given the historical baggage of Perl and the environment that a large
number of packages and modules currently expect, I don't think
decompilation will be a be total replacement for the current COP file/line
approach. But I  think it could be a welcome adjunct.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About