home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / perl / 5332 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  3.3 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!usc!news!netlabs!lwall
  2. From: lwall@netlabs.com (Larry Wall)
  3. Newsgroups: comp.lang.perl
  4. Subject: Re: Bad label: _EVAL_, inconsistent behavior
  5. Keywords: eval, setuidness, etc.
  6. Message-ID: <1992Aug15.192751.10406@netlabs.com>
  7. Date: 15 Aug 92 19:27:51 GMT
  8. References: <1992Aug14.184402.25912@rayssd.ssd.ray.com>
  9. Sender: news@netlabs.com
  10. Distribution: usa
  11. Organization: NetLabs, Inc.
  12. Lines: 53
  13. Nntp-Posting-Host: scalpel.netlabs.com
  14.  
  15. In article <1992Aug14.184402.25912@rayssd.ssd.ray.com> ras@rayssd.ssd.ray.com (Shaw) writes:
  16. : ...
  17. : Bad label: _EVAL_ at passutils.pl line 375, <STDIN> line 3.
  18. : 
  19. : I've also tried:
  20. :     eval "return \$answer if (\$answer =~ $test)";
  21. : and
  22. :     eval qq:return $answer if (\$answer =~ $test):;
  23. : as well as a few other combnations.  The "Bad label:" message
  24. : comes out on the next call to the subroutine after I've changed
  25. : something, and refers to <STDIN> line N, where N is the number of
  26. : times it's run the sub and gotten an answer.
  27. : 
  28. : Any clues?  I find no reference to _EVAL_ in the Book, and mysterious
  29. : references to the "qq" mechanism didn't seem to help either.
  30.  
  31. You're basically confusing the heck out of the runtime system by
  32. returning from something that isn't a subroutine.  The text of an eval
  33. is considered its own thing, like a parameterless subroutine.  If
  34. return were to mean anything in an eval, it should probably mean to
  35. terminate the eval itself rather than the surrounding subroutine, if any.
  36.  
  37. The gory details go like this: the subroutine, if it contains a return
  38. (and that means an ordinary return, not one embedded in an eval, which
  39. the parser can't see at compile time--your subroutine happens to have
  40. one, but your program would have blown up differently if it hadn't),
  41. pushes a mystical label _SUB_ on the label stack so the return will
  42. know where to longjmp() out to.  The eval then sets the global Boolean
  43. variable in_eval and pushes a mystical label _EVAL_ onto the label
  44. stack so that fatal errors know they are being trapped and should
  45. longjmp() back to the eval code.  When you do a return in an eval, it
  46. pops the _EVAL_ label, finds the _SUB_ label, and does a longjmp()
  47. around the eval "destructor" code that turns off the global in_eval
  48. flag, so the NEXT time you get a fatal error it tries to return to a
  49. no-longer existing _EVAL_ label.  (Yes, I could just look for an _EVAL_
  50. label instead of testing in_eval, but in_eval is used other places
  51. too.  Among other things, the tokener has to know whether it's reading
  52. from a string or from a file.  I'm planning on doing away with
  53. longjmp() anyway, so it's not really an issue in Perl 5--the
  54. "destructor" code will presumably reset in_eval correctly.)
  55.  
  56. Anyway, I'm not going to advertise a fix for it until I decide what
  57. "return" really should mean in an eval.  I don't think it's reasonable
  58. to try to pretend that evaled code is inlined--for one thing, it would
  59. mean I'd have to turn off many of the optimizations that are done in a
  60. subroutine containing an eval.  And it would be nice to have a way to
  61. short-circuit an eval or a require.  There's no way to do that
  62. conveniently at the moment without faking a fatal error, which is
  63. useless in require and even in eval has the unwanted side effect of
  64. setting $@.  If you expect return to terminate an eval in Perl 5,
  65. you're unlikely to be surprised...   :-)
  66.  
  67. Larry
  68.