A "local" just gives temporary values to global (meaning package) variables. It does not create a local variable.

print "$x, ", pos($x), "\n";
{ 
  $tmp_1 = $x;
  $x = undef;
  $x = $tmp_1;   # assign "old" value to $x, losing the pos() informat
+ion.
}
print "$x, ", pos($x), "\n";
[download]

No, local is more close to this:

{
    $orig_value = \$x;
    *x = \$tmp_new_value;
    ....;
    *x = $orig_value;
}
[download]

and the OP has reported a genuine bug

Dave.

It's a bug, yes. I'm wondering what's wrong with local() then, since your equivalent does work as you would expect local to act:

$x = 'abc de';
$x =~ m/ /g;

print "1=",pos $x;
{
    $orig_value = \$x;
    *x = \$tmp_new_value;
    print " 2=".pos $x;
#    ....;
    *x = $orig_value;
}
print " 3=".pos $$orig_value;
print " 4=".pos $x;
[download]

output:

1=4 2= 3=4 4=4
[download]

"What should it profit a man, if he should win a flame war, yet lose his cool?"

There is a workaround:

#!/usr/bin/perl -w
$x = "123 56"; 
$x =~ / /g;
print "$x, ", pos($x), "\n";
{ local *x }                     # <---
print "$x, ", pos($x), "\n";
[download]

The catch: @x, %x, &x, etc will get localized too. In other words, if you use local *_ to protect the pos of $_, you will lose access to the current @_ for the remainder of block.

I can't see how you'd reproduce this bug with it switched on.

Update: I just _knew_ someone would see this post as a challenge. I meant that, if one were using strict and declaring lexically scoped varaible, you probably wouldn't hit this, as you well know Corion.

Anyway, I thought "use vars;" was obsolete, so I'm not sure it counts? Any other offers? :)

#!/usr/bin/perl -w
use strict;
use vars qw($x);
$x = "123 56"; 
$x =~ / /g;
print "$x, ", pos($x), "\n";
{ local $x }
print "$x, ", pos($x), "\n";
[download]

Re your update, here's a version that doesn't use use vars:

#!/usr/bin/perl -w
use strict;
our $x = "123 56"; 
$x =~ / /g;
print "$x, ", pos($x), "\n";
{ local $x }
print "$x, ", pos($x), "\n";
[download]

I think you meant, "another reason to avoid using package variables".

By the way, I don't see how you got it to work with strict on. It doesn't work if you keep $x as a package variable, and local $x doesn't work if you changed $x into a lexical (i.e. used my $x).

The code you present has a striking similarity with the TODO block of this test.

I wonder what's your intention asking that here? What answer other than "yeah, that's on the TODO list for the pos operator" do you expect?

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Actually, the link you have is not the original source of the code. I added the test to the core as a TODO. The original code is actually from here.

That's a good question. From what I've read in his other threads he's not likely to answer such a direct question though.

Unfortunately, from having read all of jesuashok's nodes now, I have learned (thanks to the good detective work of monks such as liverpole and yourself) that a high percentage of them, like this one, are plagerised.

It is apparent that a fair number of them (despite having had lots of monks -- them) still have a net positive reputation.

For example, his (currently, as of 18 Nov 2006) highest scoring node (which also happens to be plagerised) at the moment has a rep of 80 even though 45 people have downvoted it.

It seems to me that he wants to increase his XP, (like money, it's a lot more important to those who don't have much of it) and he has found that by copying interesting (and as obscure as possible) questions off the Interwebs and posting them here... enough people will come along and see them and think "that's a good question" and ++ it - not knowing (or perhaps even caring? - I hope they would!) at the time that they vote on it, that it is a plagerised question.

The net result of this, even though the finding of the node may cause outrage in the monastary and score him lots of --, is that he gains XP.

Even though plagerism goes against what the monastary believes in, even though there's no personal pride in posting it (unless he has managed to sneak in some plagerised questions which he has changed enough for the originals to not be Googleable from them, so they're below the radar and haven't been picked up by us yet - perhaps he gets a kick out of that), he has learned through experience that posting other people's questions helps him get the XP he wants.

From the range of his questions, some incredibly technical and in-depth (sometimes right over my head) and some that seem so basic that I'm shocked that someone who could understand enough to post the in-depth questions would need to ask such a thing, I become more and more suspicious that there are more of his posts that have not been brought to light, but like the others are cut and pasted from other places.

I think the main potential problem would be when you're using localized $_ combined with m//g matches.

let's say you convert this (working) code:

$_ = "abcdefg";
my @some_array = (1 ..2);
while (m/./g) {
   for (@some_array) {  # implicitly localized - works
        # do something;
   }
   print $&;
}
[download]

to this (stupid but more or less equivalent) code:

$_ = "abcdefg";

while (m/./g) {
   my @some_array = (1 ..2);
   while (local $_ = shift @some_array) { # manually localized - break
+s
        # do something;
   }
   print $&;
}
[download]

Some of the parsing code i've written makes heavy use of $_ and then you can run into this problem when you're refactoring.

update: the above code breaks, because it's not the pos() function that's broken, but the match position field itself gets reset by localizing a variable - in other words, the while (m/./g) statement will loop forever.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Not an actual usage, but I could easily see something which did a match, called a sub which localized $_, and then tried to use pos() after that sub returned. Granted it'd be kinda sloppy code (like depending on $1 and friends to remain set rather than saving values off if you need to use them), but again I could see it happening.

I don't remember what I was doing, but I encountered this bug before. It was possibly in some kind of lexer or parser.