New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gotos out of conditionals. #696
Comments
From neild@zorg.hitchhiker.orgI have run across what appears to be a bug involving gotos out of # This subroutine triggers the bug. # The following code merely serves to illustrate that something has The problem is that the context stack is becoming corrupted after the The following is an excerpt from the op tree generated by the above { Here is where things go wrong. The enter op in the following subtree When pp_goto() executes, it walks up the context stack looking for It seems to me that there should be a nextstate op immediately { { The following is a patch to perly.y. It appears to correct the op tree I only modify 'if' conditionals here. I presume the same change Inline Patch--- /home/neild/Debugperl/perl5.005_03/perly.y Sat Mar 27 10:04:11 1999
+++ perly.y Sat Oct 9 22:36:06 1999
@@ -180,7 +180,8 @@
cond : IF '(' remember mexpr ')' mblock else
{ PL_copline = $1;
$$ = block_end($3,
- newCONDOP(0, $4, scope($6), $7)); }
+ newCONDOP(0, $4,
+ newSTATEOP(0, Nullch, scope($6)), $7)); }
| UNLESS '(' remember miexpr ')' mblock else
{ PL_copline = $1;
$$ = block_end($3,
Hmm. I only just now noticed that this op's LINE is now 8. (It is 3 { { Here is the only part of the tree (with the exception of the LINE value { { As I mentioned before, this is my first real foray into Perl's In particular, I don't fully understand the role of the nextstate op. - Damien Perl Info
|
From @gsarOn 10 Oct 1999 06:25:04 -0000, neild@zorg.hitchhiker.org wrote:
I put in a different fix for the same problem a few months back. Please Per my reading, it is the extra newSTATEOP() in the ELSIF production You test case above works fine with what I've got here.
pp_nextstate() is responsible for cleaning up any temporaries that
Yes. OPs that add to the context stack are all blockish constructs Sarathy |
From [Unknown Contact. See original ticket]On Sun, Oct 10, 1999 at 02:53:01AM -0700, Gurusamy Sarathy wrote:
Your change and mine share different behavior under some circumstances. sub fn { With my patch, this will print a = 2, a = 1. With your patch, this The difference, of course, is that in your patch considers all the clauses I don't really have any preference for one behavior over the other. A - Damien |
From @gsarOn Sun, 10 Oct 1999 13:06:16 PDT, Damien Neil wrote:
I don't disagree, but making them true blocks adds two "useless"
I added a single test to t/op/goto.t when I patched it, Thanks. Sarathy |
From [Unknown Contact. See original ticket]On Sun, Oct 10, 1999 at 04:20:05PM -0700, Gurusamy Sarathy wrote:
I can understand the desire not to bloat the op tree. Is the overhead The current problem is that pp_goto()/dofindlabel() don't actually Either pp_goto() needs to be modified to specifically recognize blocks
I'll write a test for this once I'm certain which behavior is going to - Damien |
From @gsarOn Sun, 10 Oct 1999 17:59:16 PDT, Damien Neil wrote:
Depends on how much the slowdown/memory bloat is. Without actually benchmarking it, I'd guess that it would be a
Doing redundant work is not very "clean". And "cleanest and most
I'd imagine that all pp_goto() needs to do would be to cook up a Another approach is to add the newSTATEOP()s as in your patch iff Sarathy |
Migrated from rt.perl.org#1594 (status was 'resolved')
Searchable as RT1594$
The text was updated successfully, but these errors were encountered: