|Come for the quick hacks, stay for the epiphanies.|
A Perl 3 bug in the debuggerby pemungkah (Priest)
|on Sep 20, 2023 at 21:25 UTC||Need Help??|
I recently posted about this on my blog, but it's worth a quick post here too.
There's a fun little bug in the debugger, which you can see like this. Create a dumb little script. Anything will do.
Now let's start up the debugger.
All as expected, but now:
That's kind of unexpected, but it gets better!
Why does this happen? well it goes back to commit a687059cbaf, which is the one that moves the debugger into lib in Perl 3. The pattern used to capture the line number specification is (\d\$\.)+, which matches all kinds of things, including floating-point numbers, IPv4 addresses, and other junk. The overall pattern used to parse the l command arguments changes over time, but that basic match to extract a "line number" never does.
You may be thinking, "yeah, okay, I see that, but why does the debugger show the floating-point line number?" The reason is that the line number spec is captured as a string. THe debugger stores the source code of the current file in an array whose name is not a valid Perl variable name, and uses the line number spec captured by the l command to index it.
When Perl indexes an array, the index value is converted to an integer if possible, because array indexes have to be integers. The line spec we have is captured and stored as a string, so when we try to index the source array with it, "1.22" becomes the integer 1, and we find line 1. The command uses the value of the index variable (remember, that's still a string!) to print the line number, and so we end up with a floating-point line number.
Now, when we run the bare l command, the string "1.22" is still in the list command's "last line listed" variable, and Perl simply takes that variable and adds 1 to its contents to look for the next line. Since the contents are a string that looks like a floating point number, Perl converts it to a float, adds 1.0 (so we don't downgrade it from a float), and assigns that back to the current line number,so we get lines 2.22, 3.22, and so on.
I've submitted a patch to fix this for 5.40, but it's pretty surprising that we've had this bug for 32 years!