From anders@broadcom.com

When you local() a tied hash, the tied-ness of the hash is not occluded.
This violates the section on "Temporary Values via local()" in the
perlsub(1) man page​:

  This means the old variable is completely invisible via the
  symbol table (i.e. the hash entry in the `*foo' typeglob)
  for the duration of the dynamic scope within which the
  `local()' was seen. This has the effect of allowing one to
  temporarily occlude any magic on composite types.

Since the actual behavior seems stable (also observed in 5.6.0 and @​9073),
it's not clear whether it makes more sense to change perl or its
documentation.

Here's a test that expects perl to work according to the man page​:

----- BEGIN t/lib/tiestdhash.t -----

#!./perl -w

BEGIN {
  chdir 't' if -d 't';
  unshift @​INC, '../lib';
}

use strict;
use Tie​::Hash;

use vars qw/%a %b/;

tie %b, 'Tie​::StdHash';
print tied(%b) ? "ok 1\n" : "not ok 1\n";

$a{Z}=1;
$b{Z}=1;
{
  local(%a, %b);
  $a{Z}=2;
  $b{Z}=2;
  print tied(%b) ? "not ok 2\n" : "ok 2\n";
  print $a{Z}==2 ? "ok 3\n" : "not ok 3\n";
  print $b{Z}==2 ? "ok 4\n" : "not ok 4\n";
}
print $a{Z}==1 ? "ok 5\n" : "not ok 5\n";
print $b{Z}==1 ? "ok 6\n" : "not ok 6\n";

----- END t/lib/tiestdhash.t -----

Site configuration information for perl 5.00503​:

Configured by root at Fri Jun 16 10​:37​:29 PDT 2000.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=solaris, osvers=2.6, archname=sun4-solaris
  uname='sunos dns-sj1-4 5.6 generic_105181-19 sun4u sparc sunw,ultra-5_10 '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='cc', optimize='-O', gccversion=
  cppflags=''
  ccflags =''
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =''
  libpth=/lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
  libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-KPIC', lddlflags='-G'

From @muir

Still present in 5.8.3.
My opinion is that this is a bug in perl (not the documentation).

On the other hand,

tie my %x, 'Tie​::Hash';
local($x{y});

should not work. I haven't tried it :-)

From @gannett-ggreer

On Mon Mar 12 11​:01​:51 2001, anders@​broadcom.com wrote​:

When you local() a tied hash, the tied-ness of the hash is not
occluded.
This violates the section on "Temporary Values via local()" in the
perlsub(1) man page​:

This means the old variable is completely invisible via the
symbol table \(i\.e\. the hash entry in the \`\*foo' typeglob\)
for the duration of the dynamic scope within which the
\`local\(\)' was seen\.  This has the effect of allowing one to
temporarily occlude any magic on composite types\.

Since the actual behavior seems stable (also observed in 5.6.0 and
@​9073),
it's not clear whether it makes more sense to change perl or its
documentation.

Here's a test that expects perl to work according to the man page​:

----- BEGIN t/lib/tiestdhash.t -----

#!./perl -w

BEGIN {
chdir 't' if -d 't';
unshift @​INC, '../lib';
}

use strict;
use Tie​::Hash;

use vars qw/%a %b/;

tie %b, 'Tie​::StdHash';
print tied(%b) ? "ok 1\n" : "not ok 1\n";

$a{Z}=1;
$b{Z}=1;
{
local(%a, %b);
$a{Z}=2;
$b{Z}=2;
print tied(%b) ? "not ok 2\n" : "ok 2\n";
print $a{Z}==2 ? "ok 3\n" : "not ok 3\n";
print $b{Z}==2 ? "ok 4\n" : "not ok 4\n";
}
print $a{Z}==1 ? "ok 5\n" : "not ok 5\n";
print $b{Z}==1 ? "ok 6\n" : "not ok 6\n";

IIRC, DaveM made it explicit recently that scalars keep tie under local
but arrays and hashes do not. Although it does pass its tests under
v5.13.3-121-gda1010e whereas Perl 5.12.1 and 5.10.1 do not, so maybe it
does work the way the requestor wanted?

Could you weigh in on whether this bug report should be therefore
rejected or resolved please?

--
George Greer

From @iabyn

Yes, it was a bug in perl that's been fixed in 5.13.1

@iabyn - Status changed from 'open' to 'resolved'