Re^5: No Pause on Elsif in Debugger (history)

My somewhat wild conjecture is that this is related to how line numbers are reported incorrectly for elsif code (the number of the line of the if is reported instead).

The broken line numbering is clearly a bug and justifies more effort be marshaled to fix it than the debugger issue.

Further, I conjecture that both are somewhat affected by the Perl4 optimization where a suitable if/elsif/else chain is converted into an efficient 'switch statement' (computed goto).

- tye

Comment on Re^5: No Pause on Elsif in Debugger (history)

Replies are listed 'Best First'.
Re^6: No Pause on Elsif in Debugger (history) by QM (Parson) on Jul 26, 2004 at 00:57 UTC
Further research...given this: `#!/your/perl/here use strict; use warnings; my $rand = rand; if ( $rand < rand ) { print "if1: $rand\n"; } elsif ( $rand < rand ) { print "elsif2: $rand\n"; } else { print "else3: $rand\n"; }` [download] works fine. Changing line 11 to: `elsif ( ( $rand < rand ) { print "elsif2: $rand\n"; }` [download] gives the error: `syntax error at C:\if_elsif.pl line 12, near ") {"` [download] But using this version instead: `elsif ( $rand < _rand ) { print "elsif2: $rand\n"; }` [download] gives the compile error: `Bareword "_rand" not allowed while "strict subs" in use at C:\if_elsif +.pl line 7.` [download] Given that you can chain `elsif`s together indefinitely, it is possible to cause an error at any line after line 7, but still be pointed to line 7. You may be wondering what happens if `use strict` is turned off - it just generates a warning instead: `Argument "_rand" isn't numeric in numeric lt (<) at C:\Perl\perlmonks\ +if_elsif.pl line 7.` [download] Turning off `warnings` then doesn't complain. I was unable to generate a message that pointed to some line besides the line of the actual error +/-1. Only turning on `strict` and `warnings` caused misleading messages. So it appears (from minimial empirical evidence) that syntax errors generate mostly correct line numbers, but `strict` and `warnings` do not, probably because information about the structure of the `if/elsif/else` has been removed from the [insert appropriate entity name here] However, if another `if/elsif/else` is nested in one of the `if` blocks, it's `if` entry point is retained (but it's `elsif/else` info is not). The remaining question I have is: What information is thrown out, and at what stage of the compilation/execution? [The original question, "Why doesn't the debugger pause on `elsif` conditionals?", seems to hinge on the answer to this new question.] -QM -- Quantum Mechanics: The dreams stuff is made of	[reply] [d/l] [select]
Re^7: No Pause on Elsif in Debugger (history) by ysth (Canon) on Jul 26, 2004 at 01:19 UTC
What information is thrown out, and at what stage of the compilation/execution? IIRC, after compilation, line numbers are only stored for the beginning of each statement. Errors generated by the lexer or parser (e.g. "syntax error") use the actual line being parsed, but any other perl error is going to show the beginning line of the statement. Does that help?	[reply]