With reference only to the first part of your OPed question, I agree with Laurent_R's explanations here and here.

Here's another way to think about the issue that might offer some confidence and comfort, for all it's long-windedness. (I don't doubt that you understand all this perfectly well, but perhaps someone else may benefit from this blatheration.) With reference to the OPed code:

• A simple
      do { local %h; }
  expression saves the original content of the package variable referenced by the  %h symbol and default-initializes a new storage location with the same symbolic name within the scope of the do expression. This new storage location is entirely separate from and independent of the storage location originally associated with the  %h symbol prior to the execution of the local statement in the do-expression. At the end-of-scope of the do-expression, any new storage space allocated within the scope of the do-expression is released (because there is no further reference to it) and the  %h symbol reverts to its old, saved symbolic referent.
•     do { local %h = (a => '3'); }
  does the same and then explictly initializes the new storage location. Again, the newly initialized storage is released at the end-of-scope of the do-expression because there is no longer any reference to it.
•     do { local %h = (a => '3');  \%h; }
  further takes the reference address of the new (and newly initialized) storage location. The do-expression now evaluates to this reference address, but if nothing more is done with the reference address, nothing can ever access the new storage created within the do-expression and this storage is released and (eventually) garbage-collected.
• The complete statement
      my $x = do { local %h = (a => '3');  \%h; };
  does save the reference address produced by evaluation of the do-expression, so the storage just created within the scope of the do-expression cannot be released. (However, the  %h symbol still "snaps back" at the end-of-scope of the do-expression.) The reference address produced by evaluation of the do-expression survives, and the storage space associated with it will only be released once all copies of this reference to it (e.g., the  $x variable) have passed out of scope.

... I'm wondering if it's "safe" ...

Yes, Dr. Szell, it's perfectly safe.

I may be wrong, but I can't see why it wouldn't be safe to do that. And I don't even think it is magic.

Or did I perhaps miss something about your concerns?

Thanks for the reply! My main concern is that I haven't yet found a description of the behavior in the perldocs or (so far) elsewhere.

So while you are right that the behavior does seem logical, there is another possible interpretation of the code: One might expect that after the effects of the local are over, $x and $y could refer back to the original %h, instead of some anonymous hashes. I'm not saying this interpretation is better or worse than the actual behavior, just that it'd be nice if it were documented.

Another concern is that perlsub says "This operator works by saving the current values of those variables in its argument list on a hidden stack and restoring them upon exiting the block, subroutine, or eval." - So the values are saved on a stack and presumably the temporary value is popped back off when the scope exits. Without some reassurance from the docs, one might worry that the temporary variables might somehow "go away" when the scope exits (e.g. is this stack refcounted?) and a reference to such a value might become invalid (however unreasonable or not the worry might be).

One might expect that after the effects of the local are over, $x and $y could refer back to the original %h,

Why should it? $x and $y are assigned to the value returned by the do block. And this value happens to be an anonymous hash ref produced within the block. And $x does not know anything about the %h hash. The fact that %h is restored to an empty hash immediately thereafter is irrelevant to the value acquired by $x at the time of the assignment.

Well, I understand your concern, but I do not think there is any reason to worry here. I think the behavior is quite clear.

G'day haukex,

What you've described here, with respect to local, is pretty much how I've always understood this to work: no dark arts or black magic; effectively, just a simple pushing and popping of a stack.

In a subsequent reply, you referenced "perlsub: Temporary Values via local()" and then wrote: "Without some reassurance from the docs, one might worry that the temporary variables might somehow "go away" when the scope exits ...". The following code tracks %h through a do block (similar to your code); in addition, do contains an anonymous block which creates new temporary values. It also tracks the lexical $r: declared but uninitialised before do; assigned a value within the anonymous block; and shown to retain that value after do.

#!/usr/bin/env perl

use strict;
use warnings;

use Data::Dump;

my $r;

print "\$r UNDEF\t"; dd $r;

our %h = (z => 26);

print "%h BEFORE do\t"; dd \%h;

my $x = do {
    print "PRE local\t"; dd \%h;

    local %h;

    print "POST local\t"; dd \%h;

    %h = (a => 1);

    print "POST assign\t"; dd \%h;

    print "%h BEFORE anon\t"; dd \%h;

    {
        print "PRE local2\t"; dd \%h;

        local %h;

        print "POST local2\t"; dd \%h;

        %h = (b => 2);

        print "POST assign2\t"; dd \%h;

        $r = \%h;

        print "\$r ASSIGNED\t"; dd $r;
    }

    print "%h AFTER anon\t"; dd \%h; 

    \%h;
};

print "%h AFTER do\t"; dd \%h;
print "\$x AFTER do\t"; dd $x;
print "\$r FINAL\t"; dd $r;
[download]

Output:

$r UNDEF        undef
%h BEFORE do    { z => 26 }
PRE local       { z => 26 }
POST local      {}
POST assign     { a => 1 }
%h BEFORE anon  { a => 1 }
PRE local2      { a => 1 }
POST local2     {}
POST assign2    { b => 2 }
$r ASSIGNED     { b => 2 }
%h AFTER anon   { a => 1 }
%h AFTER do     { z => 26 }
$x AFTER do     { a => 1 }
$r FINAL        { b => 2 }
[download]

Hopefully, that's a bit more reassuring. :-)

FWIW. I went on to use my version of gensym very extensively in some heavily threaded code and it never gave me any problems.

I don't have access to that code any more, but I might find something if I dig around on my archive CDs.

Thanks and don't worry too much about digging it out, knowing that it was used successfully is a good start! :-)

Thank you Laurent, BrowserUk, AnomalousMonk, and Ken for the explanations and reassurances :-)

It does certainly make sense that the memory allocated for the localized data structures is subject to Perl's usual memory management, that is basically what I was hoping for, but couldn't immediately confirm, so thank you for your explanations. Here's another quick test I did:

use Devel::Refcount qw/refcount/;
my $x;
our %h = (one=>'two');
{ local %h = (three=>'four');
  $x = \%h;
  print "$x ", refcount($x), "\n"; }
print "$x ", refcount($x), "\n";
__END__
HASH(0x2fb246a) 2
HASH(0x2fb246a) 1
[download]