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

Get-magic is ignored on retval of @INC hook #11793

Closed
p5pRT opened this issue Dec 11, 2011 · 8 comments
Closed

Get-magic is ignored on retval of @INC hook #11793

p5pRT opened this issue Dec 11, 2011 · 8 comments

Comments

@p5pRT
Copy link

p5pRT commented Dec 11, 2011

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

Searchable as RT105908$

@p5pRT
Copy link
Author

p5pRT commented Dec 11, 2011

From @cpansprout

sub TIESCALAR { bless \$_[0] }
sub FETCH { ${$_[0]} }
unshift @​INC, sub { tie $x, "", sub { warn "called"; $_ = 1; 0} };
require foo;

That program gives​:

foo.pm did not return a true value at - line 4.

I would expect​:

called at - line 3.


Flags​:
  category=core
  severity=low


Site configuration information for perl 5.15.4​:

Configured by sprout at Wed Nov 2 09​:06​:14 PDT 2011.

Summary of my perl5 (revision 5 version 15 subversion 4) configuration​:
  Snapshot of​: f364061
  Platform​:
  osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0​: fri nov 5 23​:20​:39 pdt 2010; root​:xnu-1504.9.17~1release_i386 i386 '
  config_args='-de -Doptimize=-g -Dusedevel -Duseithreads -Dmad'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-g',
  cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 


@​INC for perl 5.15.4​:
  /usr/local/lib/perl5/site_perl/5.15.4/darwin-thread-multi-2level
  /usr/local/lib/perl5/site_perl/5.15.4
  /usr/local/lib/perl5/5.15.4/darwin-thread-multi-2level
  /usr/local/lib/perl5/5.15.4
  /usr/local/lib/perl5/site_perl
  .


Environment for perl 5.15.4​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Nov 4, 2017

From zefram@fysh.org

The test case that you gave doesn't make sense; it seems to be a mishmash
of two different approaches to demonstrating the issue. Nevertheless,
it is correct that get magic wasn't applied there in 5.15.4. A test
case that makes sense is​:

$ perl5.15.4 -lwe 'sub TIESCALAR { my $z = $_[1]; bless \$z } sub FETCH { warn "fetched"; ${$_[0]} } unshift @​INC, sub { tie my $x, "main", "123"; \$x }; require foo'
foo.pm did not return a true value at -e line 1.

This apparently got fixed in 5.19.4, and now the test case passes​:

$ perl5.27.5 -lwe 'sub TIESCALAR { my $z = $_[1]; bless \$z } sub FETCH { warn "fetched"; ${$_[0]} } unshift @​INC, sub { tie my $x, "main", "123"; \$x }; require foo'
fetched at -e line 1.

This ticket can be closed.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Nov 4, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT p5pRT closed this as completed Nov 15, 2017
@p5pRT
Copy link
Author

p5pRT commented Nov 15, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Nov 15, 2017

From @cpansprout

On Sat, 04 Nov 2017 16​:05​:46 -0700, zefram fysh.org wrote​:

This apparently got fixed in 5.19.4, and now the test case passes​:

$ perl5.27.5 -lwe 'sub TIESCALAR { my $z = $_[1]; bless \$z } sub
FETCH { warn "fetched"; ${$_[0]} } unshift @​INC, sub { tie my $x,
"main", "123"; \$x }; require foo'
fetched at -e line 1.

This ticket can be closed.

-zefram

For the record, it seems I fixed it​:

commit 536ac39
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Fri Aug 9 08​:42​:32 2013 -0700

  Tying $_ in @​INC filter
 
  Crazy? Probably. But the existing code partially handles magic val-
  ues already; it’s just buggy. Also, the magic value could come from
  another source filter that is not registered via @​INC, and this is one
  way to test that code path.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 15, 2017

From [Unknown Contact. See original ticket]

On Sat, 04 Nov 2017 16​:05​:46 -0700, zefram fysh.org wrote​:

This apparently got fixed in 5.19.4, and now the test case passes​:

$ perl5.27.5 -lwe 'sub TIESCALAR { my $z = $_[1]; bless \$z } sub
FETCH { warn "fetched"; ${$_[0]} } unshift @​INC, sub { tie my $x,
"main", "123"; \$x }; require foo'
fetched at -e line 1.

This ticket can be closed.

-zefram

For the record, it seems I fixed it​:

commit 536ac39
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Fri Aug 9 08​:42​:32 2013 -0700

  Tying $_ in @​INC filter
 
  Crazy? Probably. But the existing code partially handles magic val-
  ues already; it’s just buggy. Also, the magic value could come from
  another source filter that is not registered via @​INC, and this is one
  way to test that code path.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 16, 2017

From @cpansprout

On Wed, 15 Nov 2017 12​:56​:42 -0800, sprout wrote​:

On Sat, 04 Nov 2017 16​:05​:46 -0700, zefram fysh.org wrote​:

This apparently got fixed in 5.19.4, and now the test case passes​:

$ perl5.27.5 -lwe 'sub TIESCALAR { my $z = $_[1]; bless \$z } sub
FETCH { warn "fetched"; ${$_[0]} } unshift @​INC, sub { tie my $x,
"main", "123"; \$x }; require foo'
fetched at -e line 1.

This ticket can be closed.

-zefram

For the record, it seems I fixed it​:

commit 536ac39
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Fri Aug 9 08​:42​:32 2013 -0700

Tying $\_ in @&#8203;INC filter

Sorry, wrong commit but same branch. This is it​:

commit 2e8409a
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Fri Aug 9 13​:32​:30 2013 -0700

  Handle magical return values from @​INC filter
 
  An @​INC filter (a subroutined returned by a subroutine in @​INC) could
  be an lvalue sub that returns a magical scalar for the status. We
  need to account for that.
 
  If we don’t call get-magic (FETCH), we’ll get the last value assigned
  to or returned from that scalar.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 16, 2017

From [Unknown Contact. See original ticket]

On Wed, 15 Nov 2017 12​:56​:42 -0800, sprout wrote​:

On Sat, 04 Nov 2017 16​:05​:46 -0700, zefram fysh.org wrote​:

This apparently got fixed in 5.19.4, and now the test case passes​:

$ perl5.27.5 -lwe 'sub TIESCALAR { my $z = $_[1]; bless \$z } sub
FETCH { warn "fetched"; ${$_[0]} } unshift @​INC, sub { tie my $x,
"main", "123"; \$x }; require foo'
fetched at -e line 1.

This ticket can be closed.

-zefram

For the record, it seems I fixed it​:

commit 536ac39
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Fri Aug 9 08​:42​:32 2013 -0700

Tying $\_ in @&#8203;INC filter

Sorry, wrong commit but same branch. This is it​:

commit 2e8409a
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Fri Aug 9 13​:32​:30 2013 -0700

  Handle magical return values from @​INC filter
 
  An @​INC filter (a subroutined returned by a subroutine in @​INC) could
  be an lvalue sub that returns a magical scalar for the status. We
  need to account for that.
 
  If we don’t call get-magic (FETCH), we’ll get the last value assigned
  to or returned from that scalar.

--

Father Chrysostomos

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

No branches or pull requests

1 participant