4 ms·

The dynamic scoping in Perl seems a bit troublesome to me. Maybe even a security issue. Can you prevent functions you call from accessing variables in your scop

The dynamic scoping in Perl seems a bit troublesome to me. Maybe even a security issue. Can you prevent functions you call from accessing variables in your scope? Do you have to somehow sanitize your scope if this is an issue? Seems a little bit worrying. With the exception of closures inside nested functions, I wish functions just had their own scope and if you want them to have anything else, just pass it in.

rmah 13y ago
When I first started using perl, I too, worried about this and other similar issues. But after 10+ years of using perl, I've never -- not once -- actually run into this problem in the real world.
- btilly 13y ago
  I have not been so lucky. I've had to submit patches to CPAN modules because their use of $_ broke dynamically scoped access to $_.
btilly 13y ago
This is why wise Perl programmers turn on use strict, and then declare variables with my. Now attempting to dynamically scope stuff is a compilation error. (Except for some built in variables, like $_. Which you don't use in real programs.) This has been standard advice since the last millennium. But you can't change it without breaking backwards compatibility. That said, I do have several good uses for local. But not normal ones. My favorite is to use local to dynamically scope entries in a hash. I wind up using this every year or two to put in an automatic check to catch infinite recursion.
- snaky 13y ago
  >variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?
  - sliverstorm 13y ago
    It's kind of obtuse. If you have to type out "$_", you might as well declare it and give it a good name. I personally have no issues doing: foreach @array { chomp; print; } But as soon as I have to type "$_" I make a real variable.
    - snaky 13y ago
      What's wrong to type $_ if you want to print "`$_'\n" in your example? Etc. I don't see any problem with that as $_ is clearly states that's a loop counter. And let's don't even talk about map/grep/sort and schwartzian transform.
      - pfortuny 13y ago
        I don't think he sees that as a Problem. Only he thinks using it explicitly is not to his taste. I have a similar attitude: make it explicitly a new var if it is going to appear in the code. Your example is perfectly OK. TIMTOWTDI, really.
    - singingfish 13y ago
      $_ is pronounced "it" and should only be used in small blocks of code. This is in much the same way that in a paragraph of text "it" should only be used for transitory sentences on the same topic as the previous one.
  - btilly 13y ago
    The problem is that $_ is global and always in package main. A specific problem that fixed this in my memory was a bug in my co-worker's code which boiled down to his looping over an array with $_, then calling a function in his loop that was in a CPAN library that assigned to $_. The result was that he wiped out his whole array. Whenever you are calling out to code that someone else wrote, you don't know if issues like that could exist, and therefore it isn't safe to use $_. Conversely if you're writing code that someone else will call, be a good citizen and don't assign to $_ either implicitly or explicitly.
- jerf 13y ago
  I like local for two big uses: One, in unit testing, it's a cheap way to completely mock out a function within some scope. I know there's various test methods for that, but frankly local'ing a glob is so easy both to use and to make do exactly what I need that it's often still easier than even invoking the library. Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request. It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....
chromatic 13y ago
Can you prevent functions you call from accessing variables in your scope? Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.

rmah 13y ago

When I first started using perl, I too, worried about this and other similar issues. But after 10+ years of using perl, I've never -- not once -- actually run into this problem in the real world.

btilly 13y ago
I have not been so lucky. I've had to submit patches to CPAN modules because their use of $_ broke dynamically scoped access to $_.

btilly 13y ago

This is why wise Perl programmers turn on use strict, and then declare variables with my. Now attempting to dynamically scope stuff is a compilation error. (Except for some built in variables, like $_. Which you don't use in real programs.) This has been standard advice since the last millennium. But you can't change it without breaking backwards compatibility. That said, I do have several good uses for local. But not normal ones. My favorite is to use local to dynamically scope entries in a hash. I wind up using this every year or two to put in an automatic check to catch infinite recursion.

snaky 13y ago
>variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?
- sliverstorm 13y ago
  It's kind of obtuse. If you have to type out "$_", you might as well declare it and give it a good name. I personally have no issues doing: foreach @array { chomp; print; } But as soon as I have to type "$_" I make a real variable.
  - snaky 13y ago
    What's wrong to type $_ if you want to print "`$_'\n" in your example? Etc. I don't see any problem with that as $_ is clearly states that's a loop counter. And let's don't even talk about map/grep/sort and schwartzian transform.
    - pfortuny 13y ago
      I don't think he sees that as a Problem. Only he thinks using it explicitly is not to his taste. I have a similar attitude: make it explicitly a new var if it is going to appear in the code. Your example is perfectly OK. TIMTOWTDI, really.
  - singingfish 13y ago
    $_ is pronounced "it" and should only be used in small blocks of code. This is in much the same way that in a paragraph of text "it" should only be used for transitory sentences on the same topic as the previous one.
- btilly 13y ago
  The problem is that $_ is global and always in package main. A specific problem that fixed this in my memory was a bug in my co-worker's code which boiled down to his looping over an array with $_, then calling a function in his loop that was in a CPAN library that assigned to $_. The result was that he wiped out his whole array. Whenever you are calling out to code that someone else wrote, you don't know if issues like that could exist, and therefore it isn't safe to use $_. Conversely if you're writing code that someone else will call, be a good citizen and don't assign to $_ either implicitly or explicitly.
jerf 13y ago
I like local for two big uses: One, in unit testing, it's a cheap way to completely mock out a function within some scope. I know there's various test methods for that, but frankly local'ing a glob is so easy both to use and to make do exactly what I need that it's often still easier than even invoking the library. Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request. It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....

chromatic 13y ago

Can you prevent functions you call from accessing variables in your scope? Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.