Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hash tied-ness doesn't local() #3561

Closed
p5pRT opened this issue Mar 12, 2001 · 7 comments
Closed

Hash tied-ness doesn't local() #3561

p5pRT opened this issue Mar 12, 2001 · 7 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Mar 12, 2001

Migrated from rt.perl.org#6017 (status was 'resolved')

Searchable as RT6017$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 12, 2001

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'

2 similar comments
@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 22, 2001

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'

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 22, 2001

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'

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 10, 2004

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 :-)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 30, 2010

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 23, 2010

From @iabyn

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 23, 2010

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.